Update Management With Azure Automation Overview
Update Management With Azure Automation Overview
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.
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
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.
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.
windows server 2012
