Skip to content

Updates and Patching of Managed VMs

OS patches for managed VMs are installed with Azure Update Manager, a Microsoft service. A maintenance configuration defines when and what is installed. You do not assign VMs by hand: a tag on the VM selects the maintenance configuration.

Schedules are platform choices

The schedules, names and times below are an example of a common set-up. Your platform has its own windows. Ask your platform team for the actual schedule. The generic rule is: the source of truth is the configuration of the maintenance configurations in the platform's code, not this page.

What you get

  • Consistent patching: all VMs with the right tag are patched on the schedule and with the update classifications of their maintenance configuration.
  • No manual assignment: after tagging, the VM is picked up automatically.
  • Automatic onboarding: new subscriptions and VMs are included without changes to the maintenance configuration.

Priorities and schedules

Systems are grouped by how much an outage or a missed patch hurts. A common classification links to the availability and integrity levels in your security classification:

Group Typical criteria Risk profile
Non-business-critical Hosts a service with the lowest classification (BIV 1) Low
Business-critical Hosts a service with a higher classification (BIV 2 and 3) Medium
Internet-connected Hosts a service that is reachable from the internet High

Typical update frequency: normal urgency patches go to non-business-critical systems first, and to business-critical systems a week later, so a bad update shows itself on the first group. Critical (urgent) patches go the same day for non-business-critical and the day after for business-critical systems.

Example of two maintenance configurations:

Configuration Start Recurrence Duration Time zone Windows classifications Linux classifications Reboot
Non-business-critical 01:00 Monthly, third Tuesday with an offset of 5 days 2 hours W. Europe Standard Time Critical, Security, Definition, Updates, UpdateRollup Critical, Security, Other If required
Business-critical 01:00 Monthly, fourth Tuesday with an offset of 5 days 2 hours W. Europe Standard Time Critical, Security, Definition, Updates, UpdateRollup Critical, Security, Other If required

A VM that does not fit any window (for example because of jobs that must finish first) can get its own maintenance configuration. Ask your platform team.

Tag your VM

Each VM needs a tag PatchPriority:

Value Maintenance configuration
non-business-critical The non-business-critical configuration
business-critical The business-critical configuration

For a VM from the Managed VM module, set the tag in the VM configuration, and switch off the module's own default maintenance configuration so that the tag decides:

"disable_default_maintenance_configuration": true,
"tags": {
  "PatchPriority": "non-business-critical"
}

Use the field names of the module version you run. If you do not use the module for a VM, add the tag by hand or in your own code. The assignment works for every VM in the subscriptions under the management group where the platform assigned the policy.

Orchestration modes

Update Manager supports customer-managed schedules (the approach on this page) and, for Linux only, the image default patching configuration, which uses the patching behaviour of the image.

Settings of a VM configuration

Setting Meaning
Maintenance window Recurrence, start time and duration when you do not use the platform-wide schedules. The module default is every Monday from 03:00 to 05:00.
Allow update reboots Whether the VM may reboot in the window. Without it, a VM that needs a reboot waits for you.
Exclude package names (Linux) Packages that are not patched. Wildcard * allowed.
Exclude KB numbers (Windows) Specific updates that are not installed.

The VM must be on

A VM must be running 40 minutes before the start of its window, or no updates are installed. For VMs with an auto-shutdown schedule the platform handles this:

  • A VM with an AutoShutdownSchedule tag that is stopped at the start of the window is started before patching and stopped again afterwards.
  • A VM that you stopped by hand is not started, and does not get its updates.

Use the schedule tag, not manual stops, for VMs that you want to switch off.

Update Manager can also run pre-events and post-events around a window. Examples: start the VM before, stop it after, or tell the workload owner that updates were installed. Allow at least 40 minutes before the start of the window for a pre-event.

Check that patching worked

After each window, look at the result for your VMs:

  1. Open Update Manager in the Azure portal, then Manage → History.
  2. Filter Update operation on Install updates and Resource type on Azure Virtual Machine.
  3. Read the status per VM:
Status Action
Succeeded None
Failed Follow up: find the reason and fix it, so it does not return
Completed with warnings Updates were installed, but with issues. Check the details.

Also read the number of updates. "8 of 10 updates installed" means two were missed, even when the VM is not marked as failed.

Check Update Manager → Machines regularly for machines under No updates data (remove filters first). Those VMs were off, have no agent or no assessment. They are not patched.

Install updates manually

Use this for VMs without a maintenance configuration.

  1. Find the VMs that miss updates: Update Manager → Resources → Machines. Filter the update classifications on Critical, Security, Update rollups and Definition updates (Windows), or Security and critical (Linux).
  2. To see which update is missing on which machines, use Manage → Pending updates with the same filters. The column Machine(s) applicable lists them.
  3. Open the VM, go to Updates and select Check for updates to run a fresh assessment. It can take a while. Follow it in the notifications pane.
  4. Select One-time update. Add more machines with Add machine if you update several at once.
  5. Select the update classifications from step 1 (Select by update classification).
  6. Check the options, then review and select Install.
  7. Follow the progress on the History tab of the VM, and check that all updates were installed.

Some VMs are patched by their owners on purpose, for example VMs that are off most of the time, hosts that need a planned reboot or domain controllers. Write them down per workload with the contact, the reason and how to update them, so a patch round does not skip them.