Updates installed via schedule updates on Azure Update Manager not reflecting the reality

Hello Bruno Leal,

Azure Update Manager only orchestrates patch execution, while the actual installation and status reporting depend on the Windows Update agent on the server.

In this case, although the maintenance configuration and event logs report success, the inconsistency across Update Manager and Get‑HotFix indicates that the update was either not fully committed, not properly reported, or not visible through Get‑HotFix limitations.

Additionally, factors such as patch orchestration settings, policy conflicts (WSUS/GPO), reboot requirements, or reporting delays can lead to discrepancies between different tools.

Recommendation

• Validate update installation using DISM or Windows Update history instead of only Get‑HotFix
• Ensure no WSUS/GPO conflicts exist
• Confirm patch orchestration is set to Customer Managed Schedules
• Review patch extension logs for execution details
• Ensure sufficient maintenance window and proper reboot handling
• Allow time for Azure reporting to synchronize

The behavior described matches known limitations and behaviors of Azure Update Manager scheduled patching and maintenance configurations. Use the following checks and adjustments to stabilize scheduled patch automation.

1. Verify patch orchestration is set correctly

Scheduled patching requires the VM’s patch orchestration to be Customer Managed Schedules:

• If the VM is still on AutomaticByOS/Windows automatic updates, scheduled patching can be inconsistent.
• Set patch orchestration to Customer Managed Schedules (Preview) (or AutomaticByPlatform with ByPassPlatformSafetyChecksOnUserSchedule) and ensure a maintenance configuration/schedule is associated only when needed.
• If the goal is that only Update Manager schedules patch the VM, ensure no conflicting OS-level automatic updates are running.

Reference behavior:

• “Patch orchestration property for Azure machines should be set to Customer Managed Schedules as it is a prerequisite for scheduled patching.”
• If patch orchestration is changed to Customer Managed Schedules and no schedule/maintenance configuration is attached, no patching occurs until explicitly configured.

2. Confirm the Windows patch update extension is healthy

For Azure VMs, the Windows patch update extension must be installed and in Succeeded state for scheduled patching and on-demand patching:

• If scheduled runs show as completed in the maintenance configuration but no updates are actually installed, verify the extension status on the VM.
• If the extension exists but status is not Succeeded, remove it and trigger an on-demand assessment or patching to reinstall it.

From the known issues:

• “The Windows/Linux patch update extension must be successfully installed on Azure machines to perform on-demand assessment or patching, scheduled patching, and periodic assessments.”

3. Check that the VM is powered on and not recently re-created

Two known behaviors can cause discrepancies between schedules and actual patching:

a) VM shutdown during schedule:

• If the VM is shut down at the scheduled time, patches are not applied and maintenance configuration associations can appear inconsistent.
• Ensure VMs are powered on at least 15 minutes before the scheduled update.

b) VM deleted/re-created with same resource ID:

• Schedules triggered on machines deleted and re-created with the same resource ID within 8 hours can fail with ShutdownOrUnresponsive and not patch correctly.
• After 8 hours, the problem no longer occurs.

4. Validate maintenance window duration vs. cumulative update requirements

Cumulative updates are large and can be skipped if the maintenance window is too short:

• Update Manager reserves 10 minutes of the maintenance window for reboot.
• Before scanning/downloading/installing, it checks if enough time remains:
  • Non–service pack updates: need at least 25 minutes (15 + 10 for reboot).
  • Service pack–type updates: need at least 30 minutes (20 + 10 for reboot).
• If less than 25 minutes remain, Update Manager skips scan/installation and may still attempt a reboot if 10 minutes remain.
• In such cases, the deployment is marked Failed with Maintenance window exceeded = true.

This can lead to:

• Event Viewer showing a successful install attempt for some components.
• Maintenance configuration showing the schedule ran.
• Azure Update Manager showing failure or no updates installed.
• Get-HotFix not listing the cumulative update because it was never fully installed.

Mitigation:

• Increase the maintenance window duration for scheduled patching, especially for cumulative updates.
• Re-run the schedule after adjusting the window and verify in Update History whether Maintenance window exceeded is still true.

5. Confirm Update Manager agent/Windows Update configuration

If Update Manager shows machines as Not assessed or inconsistent, the underlying Windows Update Agent configuration may be incorrect:

• Try installing updates locally on the server (e.g., via Windows Update GUI or sconfig/wuauclt tools). If this fails, fix the Windows Update configuration first.
• Ensure the server can reach the configured update source (Windows Update or WSUS) and any required proxy is not blocking access.

6. Review logs on the VM for scheduled runs

On Windows VMs, review the extension logs to see what happened during the scheduled run that should have installed the April cumulative update:

• VM agent log: C:\WindowsAzure\Logs\AggregateStatus (to confirm extension actions and sequence numbers).
• Patch extension logs: C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version>
  • WindowsUpdateExtension.log – details of assessed/installed patches and errors.
  • CommandExecution.log – wrapper actions and whether the patch operation was invoked for the schedule.

Compare:

• The timestamp of the scheduled maintenance window.
• The extension logs for that time to see whether:
  • The cumulative update was detected as missing.
  • Download or install failed.
  • The operation was skipped due to maintenance window checks.

7. Confirm Azure Policy prerequisites for scheduled patching

If Azure Policy is used to set up scheduled patching during VM creation (for example, policies like Schedule recurring updates using Azure Update Manager and Set prerequisite for Scheduling recurring updates on Azure virtual machines):

• Newly created, specialized, generalized, migrated, or restored VMs can show as non-compliant and may not have prerequisites or schedules attached correctly.
• Run a remediation task for these policies so that:
  • Patch orchestration is set correctly.
  • Schedules are attached as intended.

8. Stabilize the automation design

To move from ad hoc one-time updates to reliable automation:

• Ensure all target VMs:
  • Have patch orchestration set to Customer Managed Schedules.
  • Have the Windows patch update extension installed and in Succeeded state.
  • Are powered on at least 15 minutes before the schedule.
  • Have sufficient maintenance window duration (≥30 minutes for cumulative updates is recommended based on the documented thresholds).
• Avoid deleting/re-creating VMs with the same resource ID shortly before scheduled runs.
• After each schedule change, validate one or two VMs by:
  • Checking Update Manager Update History for the run.
  • Confirming no Maintenance window exceeded flag.
  • Verifying the cumulative update appears in Get-HotFix.

If discrepancies persist after these checks, use the extension logs (WindowsUpdateExtension.log and CommandExecution.log) around the scheduled time to identify whether the update was skipped, partially applied, or failed, and adjust maintenance windows or agent configuration accordingly.

References:

• Troubleshoot known issues with Azure Update Manager
• Update options and orchestration in Azure Update Manager