In the past 10 years Microsoft has provided a lot of services in Azure that could also be used “outside” of Azure, especially On Prem. We did this because by DNA, Microsoft is hybrid.
Products like Defender (for Server, SQL), Sentinel, or Log Analytics are very common. They just require a manual install of an “agent” on the remote machine and the magic begins.
This is great, but for 2 years, we have now another way to do this deployment that we recommend: Azure Arc.
- In this article, I would like to detail why you should enhance your current deployment asap. As you will see, adding Azure Arc agent will provide you with a lot of great benefits and value.
Introduction to Azure Arc
Azure Arc is a “free solution” that arrived in Azure 2 years ago.
The goal of this technology (an agent to install) is to make your remote environment visible in Azure “as if” it is natively running in Azure.
To achieve this, you simply need to run a command line on your remote machine that will download and install the Azure Arc agent. Then this Agent will register this machine in Azure Portal.
In other words, after executing this command line, you instantly get the benefits provided by Azure Arc.
Let’s see now what these benefits are.
1 – See all my remote machines in the Azure Portal, so “all my machines in one place”
The first benefit is that you will be able to see all your remote machines in the portal, in a structured way, no matter where they are located: Azure, other Cloud Providers and of course OnPrem.
By “structured” I mean that you will see the names, but also the country where they are installed, the Datacenter Name and why not even the rack number.
Here is what you get:
As you can see on this screenshot extracted from my demo environment, I have now a clear view of all my machines.
The “circle” on the server logo means “outside of Azure (Arc)”.
But this is not the end: If I click one of these machines, I get the same experience “as if” this machine was a native Azure VM. You can see if the machine is connected, the name, the version of OS but also the “Tags”.
You will see below how we can also instantly use this notion of Tags!
Benefit 1:
in 30 seconds, see all my machines in one place in a structured way.
2 – Create central reporting, leveraging all resources
As these remote machines exist now in Azure (in fact an object in a Resource Group, with properties gathered by Arc agent for free) we can create nice reports, leveraging Azure technologies such as workbooks and kusto queries.
In this example, I can see on a world MAP where my machines are located, leveraging the Tags passed during the registration of the machine:
Benefit 2:
I can leverage metadata, for example to have a graphical worldwide vision of the infrastructure, showing Azure and “OnPrem” machines.
3 – Extend Azure services On Prem, Policy Based: no more manual !
One of the major problems deploying agents manually is that we can all (as humans) make a mistake.
The great idea of “policy-based management” introduced via Azure Arc, is to create a policy centrally that will then be enforced, no matter where it is located.
A Policy could be:
- All my windows machines, running in production should run “log analytics + defender P2 + should be assessed on ISO 27001”
- All my windows machines, running in pre-production should run “log analytics + defender P1″
- All my dev/test machines, should run “log analytics on dev test workspace”
- … same logic for Linux
This is a great example of how you can adapt the health infrastructure to optimal the best “technology/rice” ratio leveraging Policies. All CTO/CSOs know now that all the machines are covered the same way!
Now we have set the policy centrally how it is triggered?
Well, when you install and register a machine via Arc, the machine “state” is analyzed by the policy (is it prod? Pre-Prod? dev test in my simple example) based on your criteria (notion of Scope) and automatically the “right components” will be deployed and enforced.
If you change the policy later, the new policy will be re-enforced automatically, no matter where this machine is running (Azure, On Prem, other clouds). Isn’t it great?
Benefit 3:
instantly switch from manual to “policy based” management, even extend your security policy posture.
4 – Focus on security products Defender for (Server/SQL), Sentinel, Log Analytics: It is Mandatory !
Security is a very important topic. We definitely don’t want to have a security breach because of human error, in my example, someone who forgot to install “manually” an agent.
With Azure Arc it is now “policy based”. So, most of the Security Product Groups (who code these Azure applications) make the Arc Agent (so the policy-based management approach) mandatory for their deployment. It just makes sense!
So for those if you who have deployed such solution manually in the past, just install the Arc Agent, and you will get the benefits described in this blog.
Benefit 4:
Have a config 100% compliant with Product Group recommendation, prevents “new versions” to fail (or side effect).
5 – Focus on Defender: split the “Azure” and the “OnPrem” machines easily
In Defender, we regroup under the term “Azure” all the machines that are in fact running in Azure, but also running on Prem. This shows that the DNA of Microsoft is hybrid.
But the side effect is that you see all these machines under “Azure”, and OnPrem sometimes has to be analyzed with a specific angle. How to fix this?
Once you have installed the Arc Agent, without doing anything, the machine will be seen by defender as an “Arc Server” in other words “A machine running outside of Azure”. Then, you can filter in the Defender GUI, and target “only” your Azure machines: 
Benefit 5: Have more granularity in Defender, to be able to analyze “together” or “separately” OnPrem et Azure.
6 – The full “hybrid” story provided by Arc for your OnPrem servers
So far, we talked about Azure Arc as a free product (on top of Defender for example) and you already can see all the value if you deploy it the agent, again in just a few minutes.
On top of Arc, you have many scenarios provided by other Azure Services. They can be deployed with the same “policy based” logic, some of them are free, some can imply a cost.
Just to give you a flavor of the potential, have a look at this quick list:
- Assess servers for patch management: Leveraging automation
- Assess servers on performance counters, event log: Log analytics
- Assess Server to Server, Service to Service “network “communication: Network MAP
- Assess running applications, name, versions, command line: Software inventory provided by automation
- …
Benefit 6: embrace the full “hybrid” power of Azure.
7 – Defender for SQL, pay less
Have a look at the pricing :
Pricing—Microsoft Defender | Microsoft Azure
2 – Microsoft Defender for SQL on Azure-connected databases price applies to SQL servers on Azure SQL Database, Azure SQL Managed Instance, Azure SQL elastic pools, Azure Synapse Analytics dedicated SQL pool, SQL on Azure Virtual Machines and SQL on Azure Arc enabled resources (in the customer’s datacenter, on the edge or in a multi-cloud environment).
3 – Microsoft Defender for SQL outside Azure price applies to SQL on non-Azure Arc-enabled resources hosted outside of Azure in the customer’s datacenter, on the edge or in a multi-cloud environment.
Recommended next steps
For all of you who have deployed solutions without Arc congratulations: you already leverage Azure products on the On Prem and see the value of these services.
We recommend you to add Azure Arc, first of all the Free Services, to go beyond and get even more value and visibility
Technically it is very easy:
-
Step 1: go in Azure Portal, go in Azure Arc, Overview then “infrastructure” sub menu. Select “Add Servers”. On the sub menu, generate the install script either for 1 server or multiple 1
- 1 server means that the command line will ask you to authenticate each time you register a server. Of course, to create a resource in Azure you need to have the right, so will ask for you to authenticate with the Devicelogin logic. Simple, but if you have multiple servers, this becomes a bit boring after a while
- Multiple is the same logic, but it will ask you to create a SPN (service provider), which will create an application identity authorized “only” to create Arc resources for a few days. Then, the command line will be “automatic” as you provide in the parameters this identity.
… of course you have to generate this script for Windows and also for Linux.
At this level you are ready to go!
- Step 2: just go on a server (SSH or RDP) run the command line, then you will see your machine displayed in Azure, Arc section
Interesting readings
I advise you to dig in this scenario to have a look at these links. A lot of them come directly from the Product Groups.
- Discover all Azure services deployed on top of Arc, and how to extend the value of the data with workbooks and Kusto queries
BoostValue: workbooks and Kusto – Fred’s Blog (esnouf.net)
- How to deploy Sentinel with Arc
- How to deploy Defender with Arc
Connect your non-Azure machines to Microsoft Defender for Cloud | Microsoft Docs
- Interesting readings
For those of you who speak French I recommend having a look at these videos. Stanislas Quastana is one our great partner engineer, with great content… and he started this discussion with Product Group member David Trigano. That was a few month ago, but still great content regarding Defender (used to be call Security Center):
Azure Defender for SQL Server – A la source d’Azure Security Center – partie 1 – YouTube
Azure Defender for servers – A la source d’Azure Security Center – partie 4.1 – YouTube
Azure Defender for servers – A la source d’Azure Security Center – partie 4.2 – 100% démos – YouTube