Azure Automanage (The Fallout)

Distibuted datacenter

Last week I did a overview of Azure Automanage for Virtual Machines, but left the service run for few days.

Just a quick memory refresh, this is a bundle of services that enable management and monitoring of virtual machines.

Azure Automanage services
Azure Automanage services

The service configures the virtual machines based on best practices, evolving around governance, security and operations principles.

For more information check out the previous article here

Test environment

The environment had two virtual machines deployed – DemoServer1 (Windows Server 2019) and jumphostvm1 (Windows 10 Pro).

Test virtual machines on-boarded in Azure Automanage
Test virtual machines on-boarded in Azure Automanage

There is a Log analytics workspace inside the omseasyazure resource group. All data from Azure Security Center is there. Consequently, this group, contains the automation account as well.

My Security Center policy is configured, to automatically install management and monitoring agent on all newly created virtual machines. As far as the agent deployment goes, the “confusion” relates to the underlying OS on the virtual machines. This does not apply to Windows 10 operating system.

Azure Virtual Machine best practices – Production configuration profile is used to configure the virtual machines.

Configuration profile deployed - Production
Configuration profile deployed – Production

Already deployed Recovery Services Vault was ignored. Even worse, the Automanage service created two additional Vaults, and placed each machine in separate ones.

Deployed Recovery Services Vaults
Deployed Recovery Services Vaults

I double check the status of both virtual machines. In both Recovery Vaults, the machines were backed up regularly. At the end, this is part of the Production configuration profile. The Dev/Test one does not include backup.

Assigned Recovery Services vault per machine (jumphostvm1)
Assigned Recovery Services vault per machine (jumphostvm1)

Disabing automanagement

Off-boarding machines is fairly easy process. You just need to go to the service, select the machines and press the Disable automanagement button. The process is fast.

Selecting machines to off-board
Selecting machines to off-board
Confirmation dialog box with disclaimer
Confirmation dialog box with disclaimer

As the picture above states, that the underlying services are not disabled. For this, you will need to visit each machine separately, and disable the services.

For this, I had to go to each Recovery Services Vault, and disable the backup.

Disabling Backup service agent
Disabling Backup service agent

I had to remove the machines from both Log analytics workspace where they were attached.

Disconnecting a virtual machine from log analytics workspace
Disconnecting a virtual machine from log analytics workspace

For larger number of virtual machines, run a script.

Last, but not least, check out the Azure Policy section. there will be couple of policies left behind. you will need to do some clean-up there, as well

Left over Azure Automanage policies

Conclusion

In conclusion, the service is useful and has potential, but also has flaws, and documentation is scarce.

The capability of customizing the configuration script, in more details, would be beneficial. Choosing between deployed and configured services, is a big perk.

The best practices relate to Azure services only. Most of Enterprise environments already have systems and tools in place. It would be useful to have more customization and selection options there.

The off-boarding process is tricky. Even in test scenarios, document everything. This will help you with the clean up process.

About Dimitar Grozdanov 11 Articles
Engineer. 20+ years “in the field”. Cloud Solution Architect. Trainer, Consultant. Co-founder/Supporter of Tech Communities. Speaker. Blogger. Parent. Passionate about craft beer tasting and hanging out with family and friends.

Be the first to comment

Leave a Reply

Your email address will not be published.


*