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.
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
The environment had two virtual machines deployed – DemoServer1 (Windows Server 2019) and jumphostvm1 (Windows 10 Pro).
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.
Already deployed Recovery Services Vault was ignored. Even worse, the Automanage service created two additional Vaults, and placed each machine in separate ones.
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.
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.
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.
I had to remove the machines from both Log analytics workspace where they were attached.
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
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.
Be the first to comment