Switching on Azure Monitor

After you have successfully onboarded your on-premises server systems into Azure Arc, the next step is to transfer monitoring of their logs, update management, and inventory to Azure services. First, you need to create the resources you need in Azure: an Azure Automation account, a Log Analytics workspace, and an Azure policy.

Azure Automation is a free cloud-based service for process automation, update management, and configuration management of Windows and Linux inside and outside of Azure. The service has no costs itself, but the log data stored in Azure Log Analytics is charged. You Azure Automation account is a standalone object in Azure that resembles a Microsoft or Azure account in name only. Automation accounts can be used to separate and administratively delegate automation-related resources, such as runbooks and configuration settings, from resources in other automation accounts. For example, you can use one account each for your production systems, development environments, and the local environment. Alternatively, you can use a single account to control all operating system updates for your machines with Update Management.

To create the account, go to Automation Accounts on the Azure portal and use the wizard to create a new account in your resource group (rg-AzureArc in this example). We chose admin-mag-arc-servers-automation for the Name and West Europe as the Region. In principle, the account can manage all resources in Azure regardless of the region. However, selecting a region means that you can isolate the related data and resources in a specific region if policies so require. On the Advanced tab, make sure you select System assigned under Managed Identities and then click Review + create to complete the process.

The next step is to create a new Log Analytics workspace, which is an environment deployed in Azure to store, manage, and analyze log data from services such as Azure Monitor, Microsoft Sentinel, or Microsoft Defender for Cloud. Each workspace has its own storage area and configuration but can combine data from different services. Creating a workspace costs nothing initially, but costs are incurred for data transferred to the workspace for processing and storage. On the Azure portal, select Log Analytics workspaces and use the wizard to create a new workspace with default settings in your resource group. We chose admin-magazine-arc-servers-automation-law as the Name and West Europe as the Region.

Now you need to configure the log data import to Azure. Microsoft is currently migrating the services from the legacy Log Analytics agent service to the new Azure Monitor Agent. This move was not completed at press time, and Azure Monitor Agent did not yet support all scenarios, so we used the legacy service, which Microsoft will continue to support until August 31, 2024. To do this, you need to select the Legacy agents management function below Legacy in the bar on the left. In Windows event logs , press Add windows event log and choose the system log as an example; leave the categories Error , Warning , and Information selected. Pressing Apply saves the configuration. Repeat this procedure for Linux by selecting Syslog in the bar at the top and clicking on Add facility ; add the Syslog facility with all log levels and confirm this by pressing Apply once again.

The next step is to ensure that the Windows and Linux servers managed by Arc send their log data to the Azure Log Analytics workspace. To do this, we used an Azure policy to roll out this configuration to the on-premises VMs. You can create this policy by typing Policy in the Azure search bar and clicking Assignments under Authoring in the Policy Overview page on the left. Then, select the Assign Initiative function. An initiative groups multiple related policy definitions into a single unit to facilitate management: Instead of assigning multiple individual policies, you can assign the group (initiative) in a single action. In the Azure Policy Initiative Assignment Wizard, select your subscription, including the resource group, as the Scope.

Now you need to define the initiative named Legacy – Enable Azure Monitor for VMs under Basics – Initiative definition . Select your Log Analytics workspace under Parameters , and under Remediation make sure that System Assigned Managed Identity is selected under Create a Managed Identity . You also need to set the region to match the managed resources, then use Review + create to assign the initiative. You can now click on the assignment's name to view it. View definition shows you that the initiative comprises 10 individual policies to ensure that the Log Analytics extension and the Dependency Agent are rolled out on Windows and Linux servers. Connecting the policy initiative to your resource group now ensures that all new servers added to Azure Arc are automatically given the necessary agents.

Of course, you have already added servers to Azure Arc before assigning the policy initiative. To make sure that they also benefit from the Log Analytics agent, you need to create correction tasks in the initiative assignment as a remedy. To do so, click on the initiative's assignment in Policy | Assignments and select the Create Remediation Task function. You need to create a total of four remediation tasks to apply four of the policies from the initiative to existing server objects:

• LogAnalyticsExtension_Windows_HybridVM_Deploy
• LogAnalyticsExtension_Linux_HybridVM_Deploy
• DependencyAgentExtension_Windows_HybridVM_Deploy
• DependencyAgentExtension_Linux_HybridVM_Deploy

In the settings, select your resource group in the Scope field under the Resources to remediate section and make sure that the Re-evaluate resource compliance before remediating box is checked.

In Remediation , the created remediation tasks now appear showing their current statuses (e.g., accepted, running, or succeeded). It can take several minutes for all four tasks to switch to the succeeded state. Looking at the VMs managed by Azure Arc should then show that the Microsoft Monitoring Agent and the Dependency Agent are, for example, freshly installed in the software list on Windows. On Red Hat Linux 8.7, typing

rpm -qa | grep agent

at the command line shows you that the omsagent and dependency-agent packages are installed.

Providing Updates to an Arc Server

The next point on the agenda is enabling update management for the Azure Arc servers. To do this, navigate to the Azure Automation account on the Azure portal (admin-magazine-arc-servers-automation in the example). When you get there, select Update Management in the left navigation pane and enable it by selecting the previously created Log Analytics workspace before pressing the Enable button to confirm. After a few minutes, the feature should be rolled out in Azure for your scope, and you can reload the page by clicking Update Management again before proceeding to configure it.

To do so, after deployment completes, click Manage Machines on the newly loaded Update Management page and select the Enable on all available and future machines option in the dialog box that appears. Directly below this, the dialog also lists the current Azure Arc servers that this setting currently affects. Press Enable to confirm the configuration; after we did so, it took about 15 minutes in our lab for the configuration to reach all the servers and for the servers to exchange the relevant data with Azure. When done, you can check the update status of your Azure Arc-managed servers under Automation Account | Update Management and see how many updates and which updates are missing on your servers.

To roll out the updates to the servers, you need a function for the Azure Arc VMs in the next step by switching to the Log Analytics workspace and selecting the Logs function in the left navigation area. In the query window, create a new query in Microsoft's simple, SQL-style Kusto query language by selecting Update | Distinct Computer . Select Save as function and save the query as the Get-AllArcVMs function; also use the same name for the Legacy Category box and additionally select the Save as computer group option.

Now switch back to the update management function in your Automation Account and navigate to Schedule update management . You now need one setting each to roll out updates to both Windows and Linux servers. For Windows, select the following data:

• Name: Update Windows
• Operating system: Windows
• Items to update: Groups to update | Non-Azure and the function just defined, GetAllArcVMs
• Schedule settings: Recurrence | Recurring, Recur every 1 Day

To save this schedule and repeat the steps in the same way for Linux servers press Create .

Once the schedules are set up, you can use the update management dashboard to see whether and when the updates ran and what the results of the operations were. In our lab, it took a while for the freshly installed updates to disappear from the list of missing updates on the dashboard, because the underlying Kusto query has a longish query time window. All told, update management leaves the impression of being very well thought out and clear-cut. It certain makes it easy to provide potentially globally distributed server systems with centrally managed updates.

Enabling Inventory

The final step is to configure the software inventory for Azure Arc-managed servers. To do so, navigate to your Azure Automation account and select Configuration Management | Inventory . To enable the inventory, you need to specify the Log Analytics workspace and then click Enable . Now reload the function tile, click Manage Machines at the top, and select Enable on all available and future machines. After a few minutes, the data is loaded, and depending on the server's operating system, you can view the installed software, including the version numbers and manufacturers, the Windows services, Linux daemons, and other properties directly in the Automation account under Inventory or, alternatively, under the individual server objects.