Microsoft Azure: This new tool makes it easier to manage virtual machines in the cloud

Virtual infrastructures are, at heart, like physical infrastructures. You might be able to deploy virtual machines at massive scale, but you still need to manage them. That means keeping them on the same security baseline, running the latest patches, and all without taking down networks of ten, a hundred, or even many thousands of servers. 

It’s scale that’s both the biggest benefit and the biggest danger of public clouds, which make it simple to pick a server image from a gallery, add your own software, and then deploy it in many different data centres around the world. Suddenly you’ve gone from one or two servers in a rack in your machine room to a massive global distributed architecture — all at the press of a button. 

There’s a metaphor that’s often used here, about cattle. You start with your own hand-built servers (like calves raised as pets), before moving onto a local data centre (a field full of cows with short and simple names). That’s followed by a move to co-location centres, maybe in two or three geographies (a large farm, where your cattle now have numbers rather than names, but you still know how many you have). The public cloud, with its massive, automated data centres, is more like an enormous ranch: cattle roam freely, and you don’t know how many there are until you round them up for an annual check, but that really doesn’t matter. 

Managing servers in the cloud 

The way servers are managed changes as operations scale to take advantage of the cloud. But the end point of that management shouldn’t change: users need to trust applications and businesses need to trust the data in their systems, no matter where that code is running. That adds complexity at scale, because while maintenance is mundane, it’s not easy to perform on multiple machines at the same time without disrupting users. 

The more virtual machines you have, the more expensive managing them manually becomes. That gets in the way of the savings that accrue from shifting from capital to operational expenditure. What’s needed, instead, is a way of automatically managing those systems, using the tools and services built into cloud platforms like Azure, and implementing the best practices that have been learned from years of running both the cloud provider’s own services and customers’ virtual infrastructures. 

Introducing Azure Automanage 

That’s what Azure Automanage is, a tool that distils Microsoft’s own experience and uses it to make sure that your virtual machines — both Windows and Linux — run at their best, implementing Azure best practices for reliability, security, and management. Automanage’s changes shouldn’t affect your code, only the underlying OS. 

Currently in public preview, Azure Automanage builds on existing Azure management agent features, with direct support for specific services that can be used to monitor and implement best practices. These include security tooling, update and configuration management, change tracking, and backup. It’s not a surprising set of choices, as these are the tools and services to use if you’re managing your servers yourself. 

Once you register a server into Azure Automanage it’s automatically added to the supported services, which then automatically configure themselves, and start to monitor and remediate your servers. The baseline configuration used for management is the one documented in Azure’s own Cloud Adoption Framework. 

Managing your virtual infrastructures with Azure Automanage 

Adding new servers to Automanage can be done either by making it part of the process of deploying a new virtual machine, or by using the Automanage section of the Azure Portal. Here you can select unmanaged servers, and then enable the service. Once that’s done, you can take a hands-off approach to those servers. Azure will aim to keep them in compliance with best practices, and will alert you if a server can’t be remediated. You can then concentrate on managing your applications and the services they need. It’s important to understand what services Azure Automanage is configuring, as some will have their own costs, especially if they use Azure storage or networking features. 

Some services offer additional configuration, so if your images have anti-malware software installed, you can stop Autoconfigure from deploying Microsoft Antimalware. Most, however, are either part of Azure services you’re already likely to be using, such as Log Analytics, or automatically use a free tier if you’re not already subscribed. 

If you’ve got a lot of servers, you can use Azure policy to automatically set up Automanage on all the servers that the policy applies to. This approach is best suited to large virtual infrastructures that have been in place for some time, and where you don’t want to risk accidentally missing a server when manually adding Automanage. 

SEE: Windows 10: Lists of vocal commands for speech recognition and dictation (free PDF) (TechRepublic)

With a policy in place, managed servers will stay enrolled in the service and new servers will have the service applied as soon as they’re deployed. You can use the DeployifNotExists option to avoid reconfiguring servers that are already managed. There’s the option of deploying Automanage as part of an Azure Resource Manager template, ensuring that your infrastructure definitions include it as part of any scripted infrastructure deployment. 

You can choose to define enrolled machines as either Dev/Test or Production. This separates the services that are used by Azure Automanage, as development servers aren’t seen as having the same business importance as production machines. So, for example, development machines aren’t set up for use with Azure Backup. 

Working with Azure Automanage 

Working with Automanage does need a supported operating system. Currently you’re limited to Windows Server 2012/R2 or later, including the Azure edition of Windows Server 2019, and a selection of Linux distributions. These include CentOS 7.3 and higher, RHEL 7.4 and higher, Ubuntu 16.04 and 18.04, and SLES 12. You’re also limited to specific Azure regions for now, as the service is still in preview. 

It’s important to remember that Azure Automanage only keeps your machines in a baseline best practices configuration. If you need to lock things down further, start by removing machines from the service. You can use the portal to disable auto-management at any time, although you’ll need to manually remove any deployed services you don’t want to use. 

SEE: Managing the multicloud (ZDNet/TechRepublic special feature) | Download the free PDF version (TechRepublic)  

There are similarities with the Desired State Configuration model, though Azure Automanage doesn’t have the same level of configurability. Sticking to Azure’s own best practices makes sense for now, but future releases should allow more in the way of customisation, if only to help businesses deliver infrastructures that reduce the risk of being out of compliance with local rules and regulations. 

There’s a lot to like in Azure Automanage, especially for organizations that don’t have the resources to manage large fleets of servers running in complex virtual infrastructures. With Windows and Linux support, you can use it with whatever infrastructure you’re already running, reducing the risks associated with making low-level changes. 

Microsoft Weekly Newsletter

Be your company’s Microsoft insider by reading these Windows and Office tips, tricks, and cheat sheets.
Delivered Mondays and Wednesdays

Sign up today

Also see