Azure Automation is not just about automation tasks in and for Azure. It is a cloud-based service that provides automation features for a wide range of scenarios that can be roughly divided into three basic areas, all three of which share a number of Azure Automation features, such as schedules, modules, credentials, and certificates.

The first area covers repeatable and consistent infrastructure provisioning according to the infrastructure-as-code principle. Azure Resource Manager Templates (ARMs), Azure Bicep, and Terraform are three popular technologies that can be used for this purpose. Another large sector revolves around event-based automation, such as for diagnostics and problem resolution.

The second area is automated threat analysis, which can be performed in the context of incident detection in a security information and event management (SIEM) system – one example being Microsoft Sentinel, which comes with well over 100 third-party system collectors in addition to many Azure- and Microsoft-specific collectors.

The third major area relates to orchestrating and integrating automation with other Azure services and third-party products. On the integration front, unsurprisingly, many Azure services already interact with Azure Automation. Even if you haven't actively dealt with the platform yet, you've probably come into contact with the service indirectly once or twice – for example, when creating a virtual machine in Azure. The Auto-shutdown feature in the Operations section of any Azure virtual machine (VM) is also based on Azure Automation. In this article, I look at further sample applications.

Automatic Guest System Patches

In the management section of the provisioning wizard for a new VM in the Azure portal, users have – for some time now – been able to select a number of options for patch orchestration in the Guest OS updates section (e.g., Automatic by OS (Windows Automatic Updates) ). However, this only works for selected operating systems (i.e., Windows Server 2008 R2 SP1, 2012 R2 Datacenter, 2016 Datacenter, and 2019 Datacenter).

Essentially, Azure supports automatic guest system patching, on-demand patch assessment, and on-demand patch installation only for VMs that you create from images that have the right publisher, offering, and stock keeping unit (SKU) combination within the list of theoretically supported operating system images. Unfortunately, this means custom images or other publisher, offering, and SKU combinations are not supported.

Additionally, the VM itself must meet a number of requirements for guest system patches to work. For example, the VM in question must have the Azure VM Agent for Windows or the Azure Linux Agent installed. Furthermore, Windows VMs must run the Windows Update service for Windows virtual machines. Of course, the VM needs to be able to access the configured update endpoints (e.g., if the VM is configured to use private repositories for Linux or Windows Server Update Services (WSUS) for Windows VMs. Of course, when creating a VM or using the REST API, you can enable guest system patching in PowerShell,

Set-AzVMOperatingSystem -VM $VirtualMachine -Windows-ComputerName $ComputerName -Credential $Credential -ProvisionVMAgent -EnableAutoUpdate -PatchMode "AutomaticByPlatform"

or from the Azure command-line interface (CLI):

az vm create --resource-group myResourceGroup --name myVM --image Win2019Datacenter --enable-agent --enable-auto-update --patch-mode AutomaticByPlatform

Once guest system patching is enabled, background automation (more on this later) ensures that any critical and security patches available are downloaded and automatically applied to the VM. The process starts automatically every month or when Microsoft releases new patches, with patch assessment and installation taking place automatically, although the VM might need to be restarted. To determine whether applicable patches are in place, the mechanism periodically checks each VM at 30-day intervals.

The installation itself can happen on any day, but not at peak VM times; automatic evaluation takes care of finding the best time. For supported guest operating systems (e.g., Windows Server 2022), you can also check the Enable hotpatch box at this point. The guest system is then updated without restarting the VM.

Note, however, that definition updates or other patches not classified as critical or security-relevant do not automatically reach the machine through the guest patching functionality just described. To do this – or if you want to install patches with other patch levels or in a custom maintenance window – you need the Update Management feature, which is part of the Azure Automation service. To do this, click Guest + host updates in the Operations section of an existing Azure VM, and then click Go to Update management (Figure 1).

Figure 1: Update Management occupies a major part of the Azure Automation feature set.

Update Management without Azure Automation

Update Management is a feature of Azure Automation and, in principle, the service is included in the feature scope of every Azure VM. To use the service, you need an Azure Log Analytics workspace and an Azure Automation account. The cost depends on the volume of log data you store in Log Analytics. The service itself costs nothing. If you do not yet have an Automation account and a Log Analytics workspace, you can create both as part of the Update Management deployment. The VM must be switched on to do so.

Figure 2 shows how Azure's Update Management works. Windows servers obtain updates from Azure or locally from Automation Update Management. You can see that the server to be updated – this can be an Azure VM or non-Azure VM – is connected to a Log Analytics workspace as a data source. The upper part, which relates to Azure Automation, and the lower part, which illustrates patching with WSUS or Microsoft Updates Service, are separate.

Figure 2: Interaction between Azure Automation, Windows Update, and WSUS (from Microsoft Documentation [1]).

Thanks to Log Analytics integration, each server can basically write the required information to the workspace to tell you which updates it already has or which ones are missing. It gains knowledge of these states from its local Windows Update client, communicating either with Microsoft Update or with a WSUS server. For this information, the server does not absolutely need Azure Update Management.

Update management in Azure is therefore primarily used to determine the best possible time for patching and then tell the server to apply the patch. That is, Azure Update Management is used to orchestrate efficient patching. The updates are deployed by Microsoft Update or WSUS. A word of caution: If the Windows Update Agent (WUA) is configured to send messages to WSUS, the results may differ from the Microsoft Update results displayed, depending on when WSUS last synchronized with Microsoft Update. Azure Automation itself is therefore not involved in either the deployment or the installation of the patches.

Microsoft essentially points users to Azure Automation for OS updates. However, Update Management can be used to orchestrate all kinds of patches (e.g., in connection with WSUS). Because WSUS patching is managed by Group Policy, you can patch the server without a schedule in Azure Automation and simply use the service for reporting in Log Analytics. You do not necessarily have to distribute patches with Azure Automation.

More Convenient Updating with Azure Automation

Azure Automation offers significantly more convenience when it comes to update management. If you open Azure Automation in the Azure portal, you will find all the systems on which update management is configured in the Update management section. You can also discover whether the update agent is ready on the monitored system. If important updates are missing, the status will be Non-compliant . This example uses Windows Update as the approval source and the Automatic Updates setting is for scheduled installations.

To schedule a deployment, click Schedule update deployment (Figures 3 and 4). The settings for a New update deployment with Machines to update , Update classifications , Schedule settings , Maintenance window , and so on are largely self-explanatory. In the Reboot options field you have to decide whether you want an automatic restart.

Figure 3: Setting up a new update deployment which, configured in this way, …

Figure 4: … subsequently shows up under Deployment schedules in the Update Management section of an Automation account.

Instead of activating Update Management from within the VM, you can also actively add Azure VMs directly by selecting Add Azure VMs . To access the previously mentioned linked Log Analytics workspace, go to the Related Resources | Linked workspace section.

Last but not least, Azure Automation Update Management can provide the pre- and post-steps shown in Figure 2 as Azure Automation runbooks, which allows you to enforce the processing of these runbooks in the automation schedule. Scripts like this always run on the Azure platform and not on the VM. For example, you could use them in the context of automatically starting (and stopping) Azure VMs to update VMs that are normally switched off at the desired update time.

If you also want these automation runbooks to trigger actions on the VM, you need to have a Hybrid Runbook Worker running on the VM. Activating Update Management for the first time can take up to 15 minutes.