Troubleshoot issues with Azure Update Manager
This article describes the errors that might occur when you deploy or use Azure Update Manager, how to resolve them, and the known issues and limitations of scheduled patching.
The following troubleshooting steps apply to the Azure virtual machines (VMs) related to the patch extension on Windows and Linux machines.
Azure Linux VM
To verify if the Microsoft Azure Virtual Machine agent (VM agent) is running and has triggered appropriate actions on the machine and the sequence number for the autopatching request, check the agent log for more information in
/var/log/waagent.log. Every autopatching request has a unique sequence number associated with it on the machine. Look for a log similar to
2021-01-20T16:57:00.607529Z INFO ExtHandler.
The package directory for the extension is
/status subfolder has a
<sequence number>.status file. It includes a brief description of the actions performed during a single autopatching request and the status. It also includes a short list of errors that occurred while applying updates.
To review the logs related to all actions performed by the extension, check for more information in
/var/log/azure/Microsoft.CPlat.Core.LinuxPatchExtension/. It includes the following two log files of interest:
<seq number>.core.log: Contains information related to the patch actions. This information includes patches assessed and installed on the machine and any problems encountered in the process.
<Date and Time>_<Handler action>.ext.log: There's a wrapper above the patch action, which is used to manage the extension and invoke specific patch operation. This log contains information about the wrapper. For autopatching, the log
<Date and Time>_Enable.ext.loghas information on whether the specific patch operation was invoked.
Azure Windows VM
To verify if the VM agent is running and has triggered appropriate actions on the machine and the sequence number for the autopatching request, check the agent log for more information in
C:\WindowsAzure\Logs\AggregateStatus. The package directory for the extension is
To review the logs related to all actions performed by the extension, check for more information in
C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version>. It includes the following two log files of interest:
WindowsUpdateExtension.log: Contains information related to the patch actions. This information includes patches assessed and installed on the machine and any problems encountered in the process.
CommandExecution.log: There's a wrapper above the patch action, which is used to manage the extension and invoke specific patch operation. This log contains information about the wrapper. For autopatching, the log has information on whether the specific patch operation was invoked.
Policy remediation tasks are failing for gallery images and for images with encrypted disks
There are remediation failures for VMs which have a reference to the gallery image in the Virtual Machine mode. This is because it requires the read permission to the gallery image and it is currently not part of the Virtual Machine Contributor role.
The Virtual Machine Contributor role doesn’t have enough permissions.
- For all the new assignments, a recent change is introduced to provide Contributor role to the managed identity created during policy assignment for remediation. Going forward, this will be assigned for any new assignments.
- For any previous assignments if you are experiencing failure of remediation tasks, we recommend that you manually assign the contributor role to the managed identity by following the steps listed under Grant permissions to the managed identity through defined roles
- Also, in scenarios where the Contributor role doesn’t work when the linked resources (gallery image or disk) is in another resource group or subscription, manually provide the managed identity with the right roles and permissions on the scope to unblock remediations by following the steps in Grant permissions to the managed identity through defined roles.
Unable to generate periodic assessment for Arc-enabled servers
The subscriptions in which the Arc-enabled servers are onboarded aren't producing assessment data.
Ensure that the Arc servers subscriptions are registered to Microsoft.Compute resource provider so that the periodic assessment data is generated periodically as expected. Learn more
Maintenance configuration isn't applied when VM is moved to a different subscription
When a VM is moved to another subscription, the scheduled maintenance configuration associated to the VM isn't running.
If you move a VM to a different resource group or subscription, the scheduled patching for the VM stops working as this scenario is currently unsupported by the system. You can delete the older association of the moved VM and create the new association to include the moved VMs in a maintenance configuration.
Unable to change the patch orchestration option to manual updates from automatic updates
The Azure machine has the patch orchestration option as
AutomaticByOS/Windows automatic updates and you're unable to change the patch orchestration to Manual Updates by using Change update settings.
If you don't want any patch installation to be orchestrated by Azure or aren't using custom patching solutions, you can change the patch orchestration option to Customer Managed Schedules (Preview) or
ByPassPlatformSafetyChecksOnUserSchedule and not associate a schedule/maintenance configuration to the machine. This setting ensures that no patching is performed on the machine until you change it explicitly. For more information, see Scenario 2 in User scenarios.
Machine shows as "Not assessed" and shows an HRESULT exception
- You have machines that show as
Not assessedunder Compliance, and you see an exception message below them.
- You see an
HRESULTerror code in the portal.
The Update Agent (Windows Update Agent on Windows and the package manager for a Linux distribution) isn't configured correctly. Update Manager relies on the machine's Update Agent to provide the updates that are needed, the status of the patch, and the results of deployed patches. Without this information, Update Manager can't properly report on the patches that are needed or installed.
Try to perform updates locally on the machine. If this operation fails, it typically means that there's an Update Agent configuration error.
This issue is frequently caused by network configuration and firewall problems. Use the following checks to correct the issue:
For Linux, check the appropriate documentation to make sure you can reach the network endpoint of your package repository.
For Windows, check your agent configuration as described in Updates aren't downloading from the intranet endpoint (WSUS/SCCM).
If you see an
HRESULT error code, double-click the exception displayed in red to see the entire exception message. Review the following table for potential resolutions or recommended actions.
|Resolution or action
Exception from HRESULT: 0x……C
|Search the relevant error code in the Windows Update error code list to find more information about the cause of the exception.
|Indicates network connectivity problems. Make sure your machine has network connectivity to Update Management. For a list of required ports and addresses, see the Network planning section.
|The update operation didn't finish because the service or system was shutting down.
|Windows Update service is disabled.
|If you're using a WSUS server, make sure the registry values for
WUStatusServer under the
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate registry key specify the correct WSUS server.
|There's a network connectivity problem or a problem in talking to a configured WSUS server. Check WSUS settings and make sure the service is accessible from the client.
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422)
|Make sure the Windows Update service (
wuauserv) is running and not disabled.
|An access denied error can be caused by any one of the following problems:
- Infected computer.
- Windows Update settings not configured correctly.
- File permission error with the
- Insufficient disk space on the system drive (drive C).
|Any other generic exception
|Run a search on the internet for possible resolutions and work with your local IT support.
%Windir%\Windowsupdate.log file can also help you determine possible causes. For more information about how to read the log, see Read the Windowsupdate.log file.
You can also download and run the Windows Update troubleshooter to check for any problems with Windows Update on the machine.
The Windows Update troubleshooter documentation indicates that it's for use on Windows clients, but it also works on Windows Server.
Known issues in schedule patching
- For a concurrent or conflicting schedule, only one schedule is triggered. The other schedule is triggered after a schedule is finished.
- If a machine is newly created, the schedule might have 15 minutes of schedule trigger delay in the case of Azure VMs.
- Policy definition Schedule recurring updates using Azure Update Manager with version 1.0.0-preview successfully remediates resources. However, it always shows them as noncompliant. The current value of the existence condition is a placeholder that always evaluates to false.
Schedule patching fails with error 'ShutdownOrUnresponsive'
Schedule patching hasn't installed the patches on the VMs and gives an error as 'ShutdownOrUnresponsive'.
Schedules triggered on machines deleted and recreated with the same resource ID within 8 hours may fail with ShutdownOrUnresponsive error due to a known limitation.
Unable to apply patches for the shutdown machines
Patches aren't getting applied for the machines that are in shutdown state. You might also see that machines are losing their associated maintenance configurations or schedules.
The machines are in a shutdown state.
Keep your machines turned on at least 15 minutes before the scheduled update. For more information, see Shut down machines.
Patch run failed with Maintenance window exceeded property showing true even if time remained
When you view an update deployment in Update History, the property Failed with Maintenance window exceeded shows true even though enough time was left for execution. In this case, one of the following problems is possible:
- No updates are shown.
- One or more updates are in a Pending state.
- Reboot status is Required, but a reboot wasn't attempted even when the reboot setting passed was
During an update deployment, Maintenance window utilization is checked at multiple steps. Ten minutes of the Maintenance window are reserved for reboot at any point. Before the deployment gets a list of missing updates or downloads or installs any update (except Windows service pack updates), it checks to verify if there are 15 minutes + 10 minutes for reboot (that is, 25 minutes left in the Maintenance window).
For Windows service pack updates, the deployment checks for 20 minutes + 10 minutes for reboot (that is, 30 minutes). If the deployment doesn't have the sufficient time left, it skips the scan/download/installation of updates. The deployment run then checks if a reboot is needed and if 10 minutes are left in the Maintenance window. If there are, the deployment triggers a reboot. Otherwise, the reboot is skipped.
In such cases, the status is updated to Failed, and the Maintenance window exceeded property is updated to true. For cases where the time left is less than 25 minutes, updates aren't scanned or attempted for installation.
To find more information, review the logs in the file path provided in the error message of the deployment run.
Set a longer time range for maximum duration when you're triggering an on-demand update deployment to help avoid the problem.