It really takes some time to go trough all the cool stuff announced at Microsoft Ignite this year. Out of the many things, the Azure Automanage for Virtual Machines, caught my eye. I do have a small datacenter, running in my Azure subscription – its three virtual machines (2 Domain Controllers, one File Server).
This is my test environment, where I use Azure Automation on top of it (Update Management), Microsoft Antimalware is there, the machines are connected to Log Analytics Workspace.
The issue was that the whole setup needed to be manually prepared and setup – discover of the machines, skills to onboard them, configure needed services (as mentioned above), and then monitor the infrastructure. In case of discrepancies (alerts), specific corrective measures need to be undertaken (i.e. Alerts, Azure Automate, Logic Apps)
Now if I compare the two options, Azure Automanage conveniently combines:
- Azure Automation including all the perks there (Update Management, Desired State Configuration Management, Change Tracking & Inventory)
- VM Insights
- Microsoft Antimalware
- Azure Backup
- Azure Security Center
In addition to on-boarding the virtual machines, the service will automatically monitor any discrepancies and correct them if needed. You should also be aware, that some of these packaged services, will incur additional costs. Compared to my current setup, it just step-up the game. ?
The current prerequisites, before You enable the service, are:
- Windows Virtual Machines Support only.
- Virtual Machines must be running.
- Virtual Machine can’t be in a scale-set.
- Virtual Machines are not connected to Log Analytics Workspace in different subscription.
- Does not support sandbox subscriptions (i.e. Microsoft Learn).
- User must have appropriate permissions (Contributor role with existing Automanage Account or Owner or Contributor/User Access Management roles for new Automanage Account).
- Limited region availability (West Europe, East US, West US 2, Canada Central, West Central US)
This will change, as the service evolves, of course. Its still in Public Preview.
On-boarding Virtual Machines in Azure Automanage
The process of on-boarding is rather straightforward, on an existing or when you create a new machine. Tough the Azure Portal, search for Automanage, and this will lead You to the on-boarding section of the portal.
You need three pieces of information, to onboard a VM:
- Selection of machines (eligible ones) for on-boarding
- Configuration Profile (one of the two, with Default preference set
- Automation account (default setting is to create one)
Machine is flagged as ineligible if the per-requisites are not met. For the demo purposes, I will use a new machine DemoServer1 (Windows Server 2019), and already deployed jumphostvm1 (Windows 10). The one that is not eligible is the Linux box.
There are two profiles (now), to choose from:
- Azure Virtual Machine best practices – Dev/Test configuration profile.
- Azure virtual Machine best practices – Production configuration profile.
The Dev/Test one, does not include the VM Insights Monitoring and Backup. This is because of the cost optimization, as well as the low business impact that those environments have in case of failure.
You can modify the Default Configuration preferences, but its limited to some of the packaged services. Depending on best practices profile selected, you can create new preferences for Microsoft Antimalware and/or Backup.
For Microsoft Antimalware, you can configure the real-time scanning parameters.
As far as, for Azure Backup settings, you can modify the time schedule and retention settings.
At this point, this is the only customization you can perform in the Public Preview. Once you configure the settings, the deployment will start (it will take some time) and onboard the machines.
During the deployment, an status message is deployed, informing the user about the progress. The Status column can display the following states:
- In-progress – the VM was just enabled and is being configured
- Configured – the VM is configured and no drift is detected
- Failed – the VM has drifted and we were unable to remediate
The current view, only provides with information on the status, and the option to off-board machines (Disable automanagement).
In case you need to enable this on lots of machines, there is an built-in Azure Policy. Please refer to the following article on how to do it: Enable Automanage for virtual machines through Azure Policy.
When the on-boarding process finishes, all packaged services will be enabled and configured on the machines.
Disabling the service on a VM results in the following behavior:
- The configuration of the VM and the services it is on-boarded to don’t change.
- Any charges incurred by those services remain billable and continue to be incurred.
- Any Automanage behaviors immediately stop.
Once you do that, the machine will be “evicted” from the list of automanaged machines. This does not mean that the packaged services are off boarded too. You will need to do this separately, service by service. It only means that automatic corrective measures will not be run.
What happened during deployment?
After the process finishes, there will be no centralized dashboard that will show you the configuration, aggregate the data or provide you with automation capabilities.
It will create a new Resource group, where the Azure Automanage service will be placed and will place it in East US (by default). The account is hidden.
The log analytics workspace, where the logs will be aggregated is the one that Azure Security Center uses. In my case it was omsEasyAzure workspace, and omsAutomate automation account, under which the automation will run.
To view configuration data, you will need to go to the Operations blade on the VM you want to look at.
You will need to perform configuration on everything except Microsoft Antimalware and Backup (those are configured during initial Profile deployment). You can modify some of the settings, though.
So, for Guest+host updates, and Configuration management you will need to configure the policies/scripts. Inventory and Change tracking are configured during deployment and collect the data. If the VMs have already those services configured, Automanage will not do any changes.
In my case, the Update Management was already configured (Critical and Security Patches only). DemoServer1 is part of that policy, so I started getting the notifications that the patches were missing.
The service has potential. At this stage, will help you enable few essential operations services for your VM infrastructure. Still lacks more Configuration Profile customization and configuration capabilities, that I would really like to have.
Integration with Azure Arc is something to look forward to or see how they will complement each other. People already using Arc will more than interested to know what will happen.
Yes, the service will configure packaged services, based on best practices, and it will monitor them. But, all follow up activities are still manual – you need to configure the patch policies, create dashboards/workbooks for monitoring, create alerts and automate remediation steps. But let us keep an eye on future developments.
For additional information refer to the Microsoft Docs repository.