Azure Arc is a new offering under the Azure Hybrid umbrella which offers a single interface inside of the Azure Portal (referred to as Control Plane) to manage all your Azure Virtual Machines as well as your on-premises servers (or servers registered with other cloud providers) that have been registered with Azure Arc. It works for both Windows and Linux based servers. This allows you to view all your server assets in a central location and to leverage features that were originally only available for native Azure VMs such as Azure Guest Configuration. You can also install extensions on the servers which expands the control you have over your on-premises servers from within the Azure Portal. One such extension is the PowerShell Desired State Configuration – Azure Arc extension, which you’ve guessed it allows you to deploy PowerShell DSC Configuration from the Azure Portal down onto your on-premises servers! This will be covered in a future blog post. For this article, I want to focus on what the process of registering a new Windows Server with Azure Arc looks like under the cover.
Azure Arc for Servers
At the time of writing this article, Azure Arc for Servers is still in Public Preview, so there’s a chance that some of the screenshots and instructions provided in this article change by the time the product is made Generally Available. In order to on-board an existing on-premises server to Azure Arc, you need to navigate to the Machines – Azure Arc service in the portal.
On the following screen, you will see all the servers you have on-boarded onto Azure Arc listed. If you are using Azure Arc for the first time, you will not see any servers. To register a new on-premises server with Azure Arc, you need to click on the + Add button.
Upon clicking that button, you will be brought to a page that let’s you decide what on-boarding method you want to use. You can either choose to on-board multiple servers at once (at scale) or a single server by clicking on the Generate script button.
In my case, I am trying to on-board a new Windows 2019 server named UnderTheCover which runs in my on-premises lab at home. On the Generate script screen, pick a Resource Group to use for on-boarding your server. This Resource Group represents the container in which the Azure Arc representation of your on-premises server will be stored. In my case, I will select and existing Resource Group called Azure Arc. Also, my on-premises server does not require a proxy, so I will leave the Proxy server URL box empty and click the Review + generate button (you can also go the the Tags tabs if you wish to assign Tags to your servers).
On the next screen, you will be provided with a few lines of PowerShell for you to copy and execute manually on the on-premises server you wish to on-board.
What is the On-Boarding Script Actually Doing?
Let us start by dissecting each section of the provided script:
function download() {$ProgressPreference="SilentlyContinue"; Invoke-WebRequest -Uri https://aka.ms/AzureConnectedMachineAgent -OutFile AzureConnectedMachineAgent.msi}
download
The above lines of code are very straight forward. It downloads the AzureConnectedMachineAgent.msi installer file from https://aka.ms/AzureConnectedMachineAgent and puts it in the current folder where you are executing the script from.
msiexec /i AzureConnectedMachineAgent.msi /l*v installationlog.txt /qn | Out-String
The next line of code executes the Connected Machine Agent we’ve downloaded in the previous step and generating an install log in the current folder where you’ve executed the script from. You don’t need to worry about that installation log. All you need to know is that the installer will actually put the files it installs under C:\Program Files\AzureConnectedMachineAgent\ and will register a new Azure Hybrid Instance Metadata Service on the the machine. This service runs the himds.exe executable file from the installation directory as its process and is executed with the NT SERVICE\himds identity. At this point, only the agent has been installed but it is not configured and not running anything on the server. In order for it to know how to communicate back with your Azure Portal, it needs a configuration file to exist at C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json which will specify information about the Azure subscription to associate the agent to. This configuration file will get created by running the following line of PowerShell.
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect --resource-group "
Running the above command will try to to connect you on-premises server to your Azure subscription. You will get a message asking you to connect launch a web browser, to navigate to https://microsoft.com/devicelogin and to enter the provided code. It will take a few seconds to finish the registration process, and once finished you will get a message saying: “Successfully Onboarded Resource to Azure“. At this point, you should be able to navigate back to the Machines – Azure Arc in your Azure portal and see the newly on-boarded server.
On the server, you should now see that the configuration file has been created under C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json. If you take a look at it, you will seee that it contains all the information you specified with that last PowerShell command, along with additional information such as the thumbprint of the certificate used to encrypt the communication between your on-premises server and Azure.
Now that the service is running on our on-premises server, it will start sending “hearbeat” notifications back to Azure’s Hybrid Identity Service (in my case at https://eus.his.arc.azure.com because my Resource Group is in East US). This heartbeat signal is what’s telling Azure that your on-premises server is still responsive and that it should be displayed as having a status of Connected. For example, right after registering your server with Azure, no status is displayed beside your machine until an initial heartbeat signal is received from the on-premises server which takes a few minutes to execute after the registration process finished. Heartbeat signals will be sent back to Azure every 5 minutes. You can look at the logs under C:\ProgramData\AzureConnectedMachineAgent\Logs for additional details. It take 25 minutes for a machine’s status to be updated as Offline in the Azure Portal, which means that the machine has to skip five consecutive heartbeats.
Example of a machine registered which hasn’t yet got the initial heartbeat reported back:
After the initial heartbeat was received:
When a machine server is shutdown or unresponsive:
