My 2-cents: Azure Automanage

Introduction

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 test “datacenter”, running in my Azure subscription – its three virtual machines (2 Domain Controllers, one File Server). The “datacenter” machines use both Azure Automation (Update Management) and Microsoft Antimalware. All log information is collected in Log Analytics Workspace. During initial setup lot of the tasks were executed manually. As result of that, some administrative knowledge and effort was required.

It started with discovery of the machines, and adequate skills to onboard them. Next step was configuring the needed services (as mentioned above). As part of the monitoring, specific corrective measures needed to be executed (i.e. Alerts, Azure Automate, Logic Apps)

Packaged Services

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

The service will also, monitor for any discrepancies, and automatically correct them. (additional costs might incur for using those services)

Prerequisites for enabling the service, are:

• Windows OS Support only.
• VM’s must be running.
• They can’t be in a scale-set.
• Virtual Machines can’t belong 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)

We expect this to change, as soon as it exits the Preview stage

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:

1. Selection of machines (eligible ones) for on-boarding
2. Configuration Profile (one of the two, with Default preference set
3. Automation account (default setting is to create one)

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.

Configuration Profiles

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 profiles incorporate the Best Practices, set forth by the Azure Server Management services principles, as stated in the Cloud Adoption Framework.

We had a three-part series on the Cloud Adoption Framework earlier. If You want to revisit, please follow the links: Part 1, Part 2, Part 3

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.

Automanage Deployment

User is informed about the deployment process with status messages. The Status column can display the following states:

• In-progress – VM enabled and is being configured
• Configured – VM is configured and no drift is detected
• Failed – 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.

Disable automanagement

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 configure everything except Microsoft Antimalware and Backup. You can modify some of the settings, though.

For Guest+host updates, and Configuration management you will need to configure the policies/scripts. On the other hand, Inventory and Change tracking are actively collecting data. Automanage will not do any changes on already configured services.

In my “datacenter”, Update Management was already setup. I do Critical and Security Patches only. DemoServer1 is part of that policy, so I started getting the notifications that some patches were missing.

Conclusion

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.