Azure Automation Update Management overview

03/19/2021 16 minutes to read In this article You can use Update Management in Azure Automation to manage operating system updates for your Windows and Linux virtual machines in Azure, in on-premises environments, and in other cloud environments. You can quickly assess […]

You can use Update Management in Azure Automation to manage operating system updates for your Windows and Linux virtual machines in Azure, in on-premises environments, and in other cloud environments. You can quickly assess the status of available updates on all agent machines and manage the process of installing required updates for servers.


You can’t use a machine configured with Update Management to run custom scripts from Azure Automation. This machine can only run the Microsoft-signed update script.

To download and install available Critical and Security patches automatically on your Azure VM, review Automatic VM guest patching for Windows VMs.

Before deploying Update Management and enabling your machines for management, make sure that you understand the information in the following sections.

About Update Management

Machines that are managed by Update Management rely on the following to perform assessment and to deploy updates:

  • Log Analytics agent for Windows or Linux
  • PowerShell Desired State Configuration (DSC) for Linux
  • Automation Hybrid Runbook Worker (automatically installed when you enable Update Management on the machine)
  • Microsoft Update or Windows Server Update Services (WSUS) for Windows machines
  • Either a private or public update repository for Linux machines

The following diagram illustrates how Update Management assesses and applies security updates to all connected Windows Server and Linux servers in a workspace:

Update Management workflow

Update Management can be used to natively deploy to machines in multiple subscriptions in the same tenant.

After a package is released, it takes 2 to 3 hours for the patch to show up for Linux machines for assessment. For Windows machines, it takes 12 to 15 hours for the patch to show up for assessment after it’s been released. When a machine completes a scan for update compliance, the agent forwards the information in bulk to Azure Monitor logs. On a Windows machine, the compliance scan is run every 12 hours by default. For a Linux machine, the compliance scan is performed every hour by default. If the Log Analytics agent is restarted, a compliance scan is started within 15 minutes.

In addition to the scan schedule, the scan for update compliance is started within 15 minutes of the Log Analytics agent being restarted, before update installation, and after update installation.

Update Management reports how up to date the machine is based on what source you’re configured to sync with. If the Windows machine is configured to report to Windows Server Update Services (WSUS), depending on when WSUS last synced with Microsoft Update, the results might differ from what Microsoft Update shows. This behavior is the same for Linux machines that are configured to report to a local repo instead of to a public repo.


To properly report to the service, Update Management requires certain URLs and ports to be enabled. To learn more about these requirements, see Network configuration.

You can deploy and install software updates on machines that require the updates by creating a scheduled deployment. Updates classified as optional aren’t included in the deployment scope for Windows machines. Only required updates are included in the deployment scope.

The scheduled deployment defines which target machines receive the applicable updates. It does so either by explicitly specifying certain machines or by selecting a computer group that’s based on log searches of a specific set of machines (or on an Azure query that dynamically selects Azure VMs based on specified criteria). These groups differ from scope configuration, which is used to control the targeting of machines that receive the configuration to enable Update Management. This prevents them from performing and reporting update compliance, and install approved required updates.

While defining a deployment, you also specify a schedule to approve and set a time period during which updates can be installed. This period is called the maintenance window. A 20-minute span of the maintenance window is reserved for reboots, assuming one is needed and you selected the appropriate reboot option. If patching takes longer than expected and there’s less than 20 minutes in the maintenance window, a reboot won’t occur.

Updates are installed by runbooks in Azure Automation. You can’t view these runbooks, and they don’t require any configuration. When an update deployment is created, it creates a schedule that starts a master update runbook at the specified time for the included machines. The master runbook starts a child runbook on each agent to install the required updates.

At the date and time specified in the update deployment, the target machines execute the deployment in parallel. Before installation, a scan is run to verify that the updates are still required. For WSUS client machines, if the updates aren’t approved in WSUS, update deployment fails.

Having a machine registered for Update Management in more than one Log Analytics workspace (also referred to as multihoming) isn’t supported.


Supported operating systems

The following table lists the supported operating systems for update assessments and patching. Patching requires a system Hybrid Runbook Worker, which is automatically installed when you enable the virtual machine or server for management by Update Management. For information on Hybrid Runbook Worker system requirements, see Deploy a Windows Hybrid Runbook Worker and a Deploy a Linux Hybrid Runbook Worker.


Update assessment of Linux machines is only supported in certain regions as listed in the Automation account and Log Analytics workspace mappings table.

Operating system Notes
Windows Server 2019 (Datacenter/Standard including Server Core)

Windows Server 2016 (Datacenter/Standard excluding Server Core)

Windows Server 2012 R2(Datacenter/Standard)

Windows Server 2012

Windows Server 2008 R2 (RTM and SP1 Standard) Update Management supports assessments and patching for this operating system. The Hybrid Runbook Worker is supported for Windows Server 2008 R2.
CentOS 6, 7, and 8 (x64) Linux agents require access to an update repository. Classification-based patching requires yum to return security data that CentOS doesn’t have in its RTM releases. For more information on classification-based patching on CentOS, see Update classifications on Linux.
Red Hat Enterprise 6, 7, and 8 (x64) Linux agents require access to an update repository.
SUSE Linux Enterprise Server 12, 15, and 15.1 (x64) Linux agents require access to an update repository. For SUSE 15.x, Python 3 is required on the machine.
Ubuntu 14.04 LTS, 16.04 LTS, and 18.04 LTS (x64) Linux agents require access to an update repository.


Update Management does not support safely automating update management across all instances in an Azure virtual machine scale set. Automatic OS image upgrades is the recommended method for managing OS image upgrades on your scale set.

Unsupported operating systems

The following table lists operating systems not supported by Update Management:

System requirements

The following information describes operating system-specific requirements. For additional guidance, see Network planning. To understand requirements for TLS 1.2, see TLS 1.2 enforcement for Azure Automation.


Software Requirements:

Windows agents must be configured to communicate with a WSUS server, or they require access to Microsoft Update. For hybrid machines, we recommend installing the Log Analytics agent for Windows by first connecting your machine to Azure Arc enabled servers, and then use Azure Policy to assign the Deploy Log Analytics agent to Windows Azure Arc machines built-in policy. Alternatively, if you plan to monitor the machines with Azure Monitor for VMs, instead use the Enable Azure Monitor for VMs initiative.

You can use Update Management with Microsoft Endpoint Configuration Manager. To learn more about integration scenarios, see Integrate Update Management with Windows Endpoint Configuration Manager. The Log Analytics agent for Windows is required for Windows servers managed by sites in your Configuration Manager environment.

By default, Windows VMs that are deployed from Azure Marketplace are set to receive automatic updates from Windows Update Service. This behavior doesn’t change when you add Windows VMs to your workspace. If you don’t actively manage updates by using Update Management, the default behavior (to automatically apply updates) applies.


You can modify Group Policy so that machine reboots can be performed only by the user, not by the system. Managed machines can get stuck if Update Management doesn’t have rights to reboot the machine without manual interaction from the user. For more information, see Configure Group Policy settings for Automatic Updates.


Software Requirements:

  • The machine requires access to an update repository, either private or public.
  • TLS 1.1 or TLS 1.2 is required to interact with Update Management.
  • Python 2.x installed.


Update assessment of Linux machines is only supported in certain regions. See the Automation account and Log Analytics workspace mappings table.

For hybrid machines, we recommend installing the Log Analytics agent for Linux by first connecting your machine to Azure Arc enabled servers, and then use Azure Policy to assign the Deploy Log Analytics agent to Linux Azure Arc machines built-in policy. Alternatively, if you plan to monitor the machines with Azure Monitor for VMs, instead use the Enable Azure Monitor for VMs initiative.

VMs created from the on-demand Red Hat Enterprise Linux (RHEL) images that are available in Azure Marketplace are registered to access the Red Hat Update Infrastructure (RHUI) that’s deployed in Azure. Any other Linux distribution must be updated from the distribution’s online file repository by using methods supported by the distribution.


To create and manage update deployments, you need specific permissions. To learn about these permissions, see Role-based access – Update Management.

Update Management components

Update Management uses the resources described in this section. These resources are automatically added to your Automation account when you enable Update Management.

Hybrid Runbook Worker groups

After you enable Update Management, any Windows machine that’s directly connected to your Log Analytics workspace is automatically configured as a system Hybrid Runbook Worker to support the runbooks that support Update Management.

Each Windows machine that’s managed by Update Management is listed in the Hybrid worker groups pane as a System hybrid worker group for the Automation account. The groups use the Hostname FQDN_GUID naming convention. You can’t target these groups with runbooks in your account. If you try, the attempt fails. These groups are intended to support only Update Management. To learn more about viewing the list of Windows machines configured as a Hybrid Runbook Worker, see view Hybrid Runbook Workers.

You can add the Windows machine to a user Hybrid Runbook Worker group in your Automation account to support Automation runbooks if you use the same account for Update Management and the Hybrid Runbook Worker group membership. This functionality was added in version 7.2.12024.0 of the Hybrid Runbook Worker.

Management packs

If your Operations Manager management group is connected to a Log Analytics workspace, the following management packs are installed in Operations Manager. These management packs are also installed for Update Management on directly connected Windows machines. You don’t need to configure or manage these management packs.

  • Microsoft System Center Advisor Update Assessment Intelligence Pack (Microsoft.IntelligencePacks.UpdateAssessment)
  • Microsoft.IntelligencePack.UpdateAssessment.Configuration (Microsoft.IntelligencePack.UpdateAssessment.Configuration)
  • Update Deployment MP


If you have an Operations Manager 1807 or 2019 management group connected to a Log Analytics workspace with agents configured in the management group to collect log data, you need to override the parameter IsAutoRegistrationEnabled and set it to True in the Microsoft.IntelligencePacks.AzureAutomation.HybridAgent.Init rule.

For more information about updates to management packs, see Connect Operations Manager to Azure Monitor logs.


For Update Management to fully manage machines with the Log Analytics agent, you must update to the Log Analytics agent for Windows or the Log Analytics agent for Linux. To learn how to update the agent, see How to upgrade an Operations Manager agent. In environments that use Operations Manager, you must be running System Center Operations Manager 2012 R2 UR 14 or later.

Data collection

Supported sources

The following table describes the connected sources that Update Management supports:

Connected source Supported Description
Windows agents Yes Update Management collects information about system updates from Windows agents and then starts installation of required updates.
Linux agents Yes Update Management collects information about system updates from Linux agents and then starts installation of required updates on supported distributions.
Operations Manager management group Yes Update Management collects information about system updates from agents in a connected management group.

A direct connection from the Operations Manager agent to Azure Monitor logs isn’t required. Data is forwarded from the management group to the Log Analytics workspace.

Collection frequency

Update Management scans managed machines for data using the following rules. It can take between 30 minutes and 6 hours for the dashboard to display updated data from managed machines.

The average data usage by Azure Monitor logs for a machine using Update Management is approximately 25 MB per month. This value is only an approximation and is subject to change, depending on your environment. We recommend that you monitor your environment to keep track of your exact usage. For more information about analyzing Azure Monitor Logs data usage, see Manage usage and cost.

Network planning

Check Azure Automation Network Configuration for detailed information on the ports, URLs, and other networking details required for Update Management.

For Windows machines, you must also allow traffic to any endpoints required by Windows Update. You can find an updated list of required endpoints in Issues related to HTTP/Proxy. If you have a local Windows Update server, you must also allow traffic to the server specified in your WSUS key.

For Red Hat Linux machines, see IPs for the RHUI content delivery servers for required endpoints. For other Linux distributions, see your provider documentation.

For more information about ports required for the Hybrid Runbook Worker, see Update Management addresses for Hybrid Runbook Worker.

If your IT security policies do not allow machines on the network to connect to the internet, you can set up a Log Analytics gateway and then configure the machine to connect through the gateway to Azure Automation and Azure Monitor.

Update classifications

The following table defines the classifications that Update Management supports for Windows updates.

Classification Description
Critical updates An update for a specific problem that addresses a critical, non-security-related bug.
Security updates An update for a product-specific, security-related issue.
Update rollups A cumulative set of hotfixes that are packaged together for easy deployment.
Feature packs New product features that are distributed outside a product release.
Service packs A cumulative set of hotfixes that are applied to an application.
Definition updates An update to virus or other definition files.
Tools A utility or feature that helps complete one or more tasks.
Updates An update to an application or file that currently is installed.

The next table defines the supported classifications for Linux updates.

Classification Description
Critical and security updates Updates for a specific problem or a product-specific, security-related issue.
Other updates All other updates that aren’t critical in nature or that aren’t security updates.


Update classification for Linux machines is only available when used in supported Azure public cloud regions. There is no classification of Linux updates when using Update Management in the following national cloud regions:

  • Azure US Government
  • 21Vianet in China

Instead of being classified, updates are reported under the Other updates category.

Update Management uses data published by the supported distributions, specifically their released OVAL (Open Vulnerability and Assessment Language) files. Because internet access is restricted from these national clouds, Update Management cannot access the files.

For Linux, Update Management can distinguish between critical updates and security updates in the cloud under classification Security and Others, while displaying assessment data due to data enrichment in the cloud. For patching, Update Management relies on classification data available on the machine. Unlike other distributions, CentOS does not have this information available in the RTM version. If you have CentOS machines configured to return security data for the following command, Update Management can patch based on classifications.

sudo yum -q --security check-update

There’s currently no supported method to enable native classification-data availability on CentOS. At this time, limited support is provided to customers who might have enabled this feature on their own.

To classify updates on Red Hat Enterprise version 6, you need to install the yum-security plugin. On Red Hat Enterprise Linux 7, the plugin is already a part of yum itself and there’s no need to install anything. For more information, see the following Red Hat knowledge article.

When you schedule an update to run on a Linux machine, that for example is configured to install only updates matching the Security classification, the updates installed might be different from, or are a subset of the updates matching this classification. When an assessment of OS updates pending for your Linux machine is performed, Open Vulnerability and Assessment Language (OVAL) files provided by the Linux distro vendor is used by Update Management for classification.

Categorization is done for Linux updates as Security or Others based on the OVAL files, which includes updates addressing security issues or vulnerabilities. But when the update schedule is run, it executes on the Linux machine using the appropriate package manager like YUM, APT or ZYPPER to install them. The package manager for the Linux distro may have a different mechanism to classify updates, where the results may differ from the ones obtained from OVAL files by Update Management. To manually check the machine and understand which updates are security relevant by your package manager, see Troubleshoot Linux update deployment.

Integrate Update Management with Configuration Manager

Customers who have invested in Microsoft Endpoint Configuration Manager for managing PCs, servers, and mobile devices also rely on the strength and maturity of Configuration Manager to help manage software updates. To learn how to integrate Update Management with Configuration Manager, see Integrate Update Management with Windows Endpoint Configuration Manager.

Third-party updates on Windows

Update Management relies on the locally configured update repository to update supported Windows systems, either WSUS or Windows Update. Tools such as System Center Updates Publisher allow you to import and publish custom updates with WSUS. This scenario allows Update Management to update machines that use Configuration Manager as their update repository with third-party software. To learn how to configure Updates Publisher, see Install Updates Publisher.

Enable Update Management

Here are the ways that you can enable Update Management and select machines to be managed:

  • Using an Azure Resource Manager template to deploy Update Management to a new or existing Automation account and Azure Monitor Log Analytics workspace in your subscription. It does not configure the scope of machines that should be managed, this is performed as a separate step after using the template.

  • From your Automation account for one or more Azure and non-Azure machines, including Arc enabled servers.

  • Using the Enable-AutomationSolution runbook method.

  • For a selected Azure VM from the Virtual machines page in the Azure portal. This scenario is available for Linux and Windows VMs.

  • For multiple Azure VMs by selecting them from the Virtual machines page in the Azure portal.


Update Management requires linking a Log Analytics workspace to your Automation account. For a definitive list of supported regions, see Azure Workspace mappings. The region mappings don’t affect the ability to manage VMs in a separate region from your Automation account.

Next steps

Source Article

Next Post

Services for Phoenix Businesses

Thu Mar 25 , 2021
Services for Business The city of Phoenix has a wealth of programs and activities to assist businesses, both large and small.  On these pages, find information regarding the city’s commercial development review process,  how to do business with the city, business opportunities for small and disadvantaged enterprise businesses, and privilege and sales tax information. If you […]