Welcome to part 6 of my well-tempered Azure tenant series for MSPs. This time we will take a look at Azure Arc. Very few environments are truly Cloud only or if they are then they are using a multitude of different Cloud providers. Azure Arc is a service that was launched at Microsoft Ignite 2019 and its purpose is to bring management and governance capabilities to hybrid and multi-cloud environments. This is very significant for MSPs as not only do we already have a means to manage multiple Azure customers across tenants using Azure Lighthouse but we can now extend some of these management capabilities to our customer’s on premises or multi-cloud environments as well.
Part 6: Azure Arc
So what can we do with Azure Arc today? Although initially Azure Arc was very much server focussed it is now possible through hosting your own Kubernetes clusters to deploy and manage a number of Azure data services and even some Azure application services although these are in preview at the time of writing.
Current list of supported services with Azure Arc:
Infrastructure – Virtual Machines, SQL Server, Kubernetes clusters and Azure Stack HCI
Data Services – SQL managed instances and Postgre SQL Hyperscale
Application Services (Preview) – API management, App Services, Event Grid topics, Functions and Logic Apps
We will continue to focus on infrastructure for this series of blog posts and discuss some monitoring, management and governance options for non-Azure servers.
Hybrid cloud monitoring
For an MSP, it’s important to have a unified toolset for monitoring resources regardless of their location. In the past, this meant deploying a third party RMM agent to your Azure Virtual Machines and using an external portal or desktop application to provide monitoring metrics and alerts. Given the enhancements to Azure Monitor over recent years we can now build out a powerful Azure native monitoring solution. It makes sense that this solution should be extended to non-Azure resources as well in order to provide a unified monitoring solution directly from the Azure portal.
Add your servers
We have a few options to add non-Azure Virtual Machines (servers) to Azure Arc for management. We can use deployment scripts, onboard through Azure update management (if we are already using this) or use Azure Migrate for VMware hosts.
In most cases, I find the deployment script is usually the quickest option. This will require the server that you are onboarding to have either public Internet access to the Azure Arc service or else you can use private endpoints to access this service privately over a VPN or ExpressRoute connection. This latter option is in public preview currently.
There are a few steps to the server onboarding process:
Step 1. Register your Azure subscription for Azure Arc. I recommend to register a separate instance of Azure Arc per customer. This allows MSPs to cater for different management level requirements for each customer. This will also help with split billing for any costs associated with Azure Arc rather than trying to separate out your customer costs from a single deployment of Azure Arc.
Step 2. Download and Install the Azure Arc hybrid agent. This will be a PowerShell script for Windows servers or a Bash script for Linux. This script also creates the Azure Arc management resource for your server(s) in the customer tenant and associates it with the deployed agent.
Pro tip: You will need TLS 1.2 enabled for your PowerShell session to run the script. Here’s a command to enable this for your PowerShell session.
$TLS12Protocol = [System.Net.SecurityProtocolType] 'Ssl3 , Tls12' [System.Net.ServicePointManager]::SecurityProtocol = $TLS12Protocol
Once you have completed these onboarding steps then within a few minutes you should see your Azure Arc managed servers appear in the Azure portal.
If you click on any of these onboarded servers you will see a familiar list of management options for virtual machines are now available: settings, operations, monitoring and automation. This means that to an extent we now have a unified monitoring and management solution for both Azure and non-Azure virtual machines.
Let’s first take a look at monitoring. We will be familiar with this from the previous post in this series so let’s first of all enable Virtual Machine Insights. This can be deployed per VM or at scale by using this Azure Policy assignment.
By enabling insights, not only will we be able to monitor our Azure Arc managed virtual machines but this process also deploys the Log Analytics and dependency agents that we will need for guest OS management operations in the next section.
Let’s take a look at operations now. We will see here that we can use Azure Policy to apply governance for these servers just like we can with Azure Virtual Machines, we already covered Azure Policy in part 4 of this series. Instead, let’s focus on the next few options: Update management, inventory and change tracking and enable these features for our Azure Arc managed virtual machines.
You may note the following message appears when clicking into any of these options. Each of these features is instead managed through an Automation Account so we will first have to deploy an Automation Account to make use of these features.
I recommend to use a separate Automation Account for each customer. This will be deployed to the shared ‘management’ resource group on each customer tenant that we have used in previous posts in this series.
Once you have the Automation Account deployed, you can then enable update management, inventory and change tracking by enabling this feature and selecting the Log Analytics workspace that we have also used before in previous posts in this series for each of our customer tenants.
When update management is enabled and after some time has elapsed the Azure portal should detect that you have some machines that do not have update management enabled. It’s now simply a matter of setting the manage machines settings and deciding to either enable update management for all machines, selected machines or all and any future machines that are onboarded.
If you are planning to use the inventory or changing tracking feature then you will need to onboard your machines to this service in the same manner also.
You can then create update deployment schedules for your Windows and Linux virtual machines and track the compliance state and missing updates for multiple machines per customer.
We can also track our machine inventory across multiple machines per customer.
…as well as view the change tracking information per machine.
…and this is just the servers
Onboarding your non-Azure Virtual Machines to Azure Arc has an ever growing list of benefits. These machines are now treated as Azure resources in their own right and we have covered how you can monitor and manage these machines just like an Azure native virtual machine but that is just the start.
You will also be able to query these resources using Azure Resource Graph and even onboard to Microsoft Defender for Cloud. If you are using Microsoft Sentinel, then these machines can also be connected to this service for security event log ingestion and analysis.
From a governance side, we can assign RBAC roles to these Azure resources as well as implement resource tags along with assigning Azure policies and initiatives to enforce guardrails and compliance practices.
Let’s not forget that we have only covered Azure Arc enabled servers in this post, there’s so much more available through Azure Arc enabled Kubernetes clusters.
Azure Arc is definitely a service to keep a close eye on for the future as more services become hybrid enabled and available to deploy and manage outside of Azure Cloud.
In our final post of this series we will cover Microsoft Defender for Cloud with a focus on protecting our Azure and non-Azure endpoints across customer tenants.
3 thoughts on “MSP: The well-tempered Azure tenant – Part 6”