Want to get started with Azure Arc, to get visibility & control of non-Azure resources within your Azure environment? The product group have released some scenarios and automation code to help you explore Azure Arc’s capabilities, on the Azure Arc Jumpstart website. Azure Arc is a free service, though some Azure products and services that can utilize Azure Arc enabled resources may have their own associated costs.
Azure Arc Jumpstart
The Azure Arc Jumpstart Project is a combination of instructions and code covering some of the Azure Arc capabilities, including onboarding to Azure and Azure services. It includes:
Azure Arc enabled servers
Azure Arc enabled SQL Server
Azure Arc enabled Kubernetes
Azure Arc enabled data services
There are scenarios for onboarding these resources from HashiCorp Vagrant, AWS, Google Cloud Platform, VMWare vSphere, Rancher K3s, Kind, MicroK8s and kubeadm.
Then you can explore the scenarios for operating these workloads via Azure Monitor, Azure Policy, GitOps, resource tagging, Log Analytics, Key Vault, Security Center, Azure Sentinel and Update Management. Note: not all operating scenarios apply to all resource types.
Let’s walk through onboarding an existing on-premises Windows Server, using Azure Arc Jumpstart.
First, the instructions direct you to install or update Azure CLI to version 2.7 or above, and then gives you the az commands to create an Azure service principal. The service principal is used as a set of credentials with access to make things happen in Azure, and it’s recommended that you use role-based-access control to limit the scope of this account to only have Contributor permissions within the specific Azure resource group that you will onboard your server to. To assign the role and scope to the service principal using the Azure CLI, you’ll need the service principal object ID, the unique role ID and the resource group name, following the instructions here: Add or remove Azure role assignments using Azure CLI.
If you’re more familiar with PowerShell or the Azure portal, you could use those instead to create the service principal and assign the creator role to the resource group.
Next, you’ll down a PowerShell script to download and install the Azure Arc “connected machine” agent to your existing Windows Server, and connect it to your Azure tenancy. There are a number of variables in this script you need to edit to reflect your own environment, including the subscriptionID, tenantID, resource group name, location (Azure region) and the appID and password for the service principal you created.
NOTE: Azure Arc is not supported in all regions. Check https://azure.microsoft.com/global-infrastructure/services/?products=azure-arc for supported and planned regions.
If you’re not familiar with GitHub, you’ll wonder why there’s no option to download the script’s .ps1 file. You can “fork” this repo to your own local copy or you can just copy & paste the command lines into notepad and save it as a .ps1 file locally.
Finally you’ll use PowerShell ISE running as Administrator on the existing Windows Server you want to onboard. After a short while, you’ll see that server as a new Connected Machine resource inside the Azure portal, in your designated resource group.
NOTE: If you don’t have an existing on-premises or local Hyper-V VM Windows Server, or a server in another cloud provider, you can use these steps to create a Windows Server in Azure (using an ARM template) and deploy Azure Arc to onbo… This scenario is only valid for demonstrating & testing the Azure Arc onboarding process. By default, Azure VMs already use the Azure Instance Metadata Service (IMDS) and cannot use both that and Azure Arc for operations. Using Azure Arc to support Azure VMs is not supported as they already have native Azure operational functions.
Azure Arc capabilities for your server
Once your server has been onboarded, you can explore the different management tools in Azure that can now manage your server by checking out the Unified Operations Use Cases.
A good place to start is to onboard your Azure Arc enabled server into Azure Sentinel, to include it in your Security Information and Event Management processes. This requires the creation of a Log Analytics Workspace enabled for Azure Sentinel, and for your Azure Arc enabled server to have either the Microsoft Monitoring Agent or the Sentinel agent deployed to it as an extension.
In addition, it’s recommended that you create an Azure Policy to monitor and enforce that the extension still exists on your server, to counteract accidental or malicious removal without your knowledge. See the full onboarding steps here: Connect Azure Arc enabled servers to Azure Sentinel.
This guidance and instructions are hosted on GitHub, so you are welcome to contribute to the project if you discover a bug or want to suggest a change. To find out how to contribute visit Contributing
And make sure you’ve read the Microsoft Open Source Code of Conduct.
Go and check out the Azure Arc Jumpstart Project!
Product group articles:
The Azure Arc Jumpstart Project
Azure Arc enabled Kubernetes with GitOps
In preview: Azure Key Vault extension for Arc enabled servers
Azure Arc & Azure Lighthouse: Managing IT Infrastructure Anywhere at-scale