Troubleshoot Update Management issues

Artikkeli
08/30/2024

Important

Change Tracking and Inventory using Log Analytics agent has retired on 31 August 2024 and will work on limited support till 01 February 2025. We recommend that you use Azure Monitoring Agent as the new supporting agent. Follow the guidelines for migration from Change Tracking and inventory using Log Analytics to Change Tracking and inventory using Azure Monitoring Agent version.

This article discusses issues that you might run into when using the Update Management feature to assess and manage updates on your machines. There's an agent troubleshooter for the Hybrid Runbook Worker agent to help determine the underlying problem. To learn more about the troubleshooter, see Troubleshoot Windows update agent issues and Troubleshoot Linux update agent issues. For other feature deployment issues, see Troubleshoot feature deployment issues.

Note

If you run into problems when deploying Update Management on a Windows machine, open the Windows Event Viewer, and check the Operations Manager event log under Application and Services Logs on the local machine. Look for events with event ID 4502 and event details that contain Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent.

Scenario: Windows Defender update always show as missing

Issue

Definition update for Windows Defender (KB2267602) always shows as missing in an assessment when it's installed and shows as up to date when verified from Windows Update history.

Cause

Definition updates are published multiple times in a single day. As a result, you could see multiple releases of KB2267602 published in a single day, but with a different update ID and version.

Update Management assessment runs once in 11 hours. In this example, at 10:00 AM an assessment ran and version 1.237.316.0 was available at the time. When you search the Update table in your Log Analytics workspace, the Definition update 1.237.316.0 is shown with an UpdateState of Needed. If a scheduled deployment runs a few hours later, let's say 1:00 PM and version 1.237.316.0 is still available or a newer version is, the newer version is installed and this is reflected in the record written to the UpdateRunProgress table. However, in the Update table, it would still show version 1.237.316.0 as Needed until the next assessment is run. When the assessment runs again, there may not be a newer definition update available, so the Update table would not show the definition update version 1.237.316.0 as missing or a newer version available as needed. Because of the frequency of definition updates, there could be multiple versions returned in the log search.

Resolution

Run the following log query to confirm definition updates installed are being properly reported. This query returns the time generated, version, and update ID of KB2267602 in the Updates table. Replace the value for Computer with the fully qualified name of the machine.

Update
| where TimeGenerated > ago(14h) and OSType != "Linux" and (Optional == false or Classification has "Critical" or Classification has "Security") and SourceComputerId in ((
    Heartbeat
    | where TimeGenerated > ago(12h) and OSType =~ "Windows" and notempty(Computer)
    | summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
    | where Solutions has "updates"
    | distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, *) by Computer, SourceComputerId, UpdateID
| where UpdateState =~ "Needed" and Approved != false and Computer == "<computerName>"
| render table

Your query results should return something similar to the following:

Example showing results of log query from Updates table.

Run the following log query to get the time generated, version, and update ID of KB2267602 in the UpdatesRunProgress table. This query helps us understand if it was installed from Update Management or if it was auto-installed on the machine from Microsoft Update. You need to replace the value for CorrelationId with the runbook job GUID (that is, the MasterJOBID property value from the Patch-MicrosoftOMSComputer runbook job) for the update, and SourceComputerId with the GUID of the machine.

UpdateRunProgress
| where OSType!="Linux" and CorrelationId=="<master job id>" and SourceComputerId=="<source computer id>"
| summarize arg_max(TimeGenerated, Title, InstallationStatus) by UpdateId
| project TimeGenerated, id=UpdateId, displayName=Title, InstallationStatus

Your query results should return something similar to the following:

Example showing results of log query from UpdatesRunProgress table.

If the TimeGenerated value for the log query results from the Updates table is earlier than the timestamp (that is, value of TimeGenerated) of the update installation on machine or from the log query results from the UpdateRunProgress table, then wait for the next assessment. Afterwards, run the log query against the Updates table again. Either an update for KB2267602 won't appear or it appears with a newer version. However, even after the most recent assessment if same version shows up as Needed in the Updates table but it is already installed, you should open an Azure support incident.

Scenario: Linux updates shown as pending and those installed vary

Issue

For your Linux machine, Update Management shows specific updates available under classification Security and Others. But when an update schedule is run on the machine, for example to install only updates matching the Security classification, the updates installed are different from or a subset of the updates shown earlier matching that classification.

Cause

When an assessment of OS updates pending for your Linux machine is done, 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 states 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.

Resolution

You can manually check the Linux machine, the applicable updates, and their classification per the distro's package manager. To understand which updates are classified as Security by your package manager, run the following commands.

For YUM, the following command returns a non-zero list of updates categorized as Security by Red Hat.

sudo yum -q --security check-update

For ZYPPER, the following command returns a non-zero list of updates categorized as Security by SUSE.

sudo LANG=en_US.UTF8 zypper --non-interactive patch --category security --dry-run

For APT, the following command returns a non-zero list of updates categorized as Security by Canonical for Ubuntu Linux distros.

sudo grep security /etc/apt/sources.list > /tmp/oms-update-security.list LANG=en_US.UTF8 sudo apt-get -s dist-upgrade -oDir::Etc::Sourcelist=/tmp/oms-update-security.list

From this list you then run the command grep ^Inst to get all the pending security updates.

Scenario: You receive the error "Failed to enable the Update solution"

Issue

When you try to enable Update Management in your Automation account, you get the following error:

Error details: Failed to enable the Update solution

Cause

This error can occur for the following reasons:

The network firewall requirements for the Log Analytics agent might not be configured correctly. This situation can cause the agent to fail when resolving the DNS URLs.
Update Management targeting is misconfigured and the machine isn't receiving updates as expected.
You might also notice that the machine shows a status of Non-compliant under Compliance. At the same time, Agent Desktop Analytics reports the agent as Disconnected.

Resolution

Run the troubleshooter for Windows or Linux, depending on the OS.
Go to Network configuration to learn about which addresses and ports must be allowed for Update Management to work.
Check for scope configuration problems. Scope configuration determines which machines are configured for Update Management. If your machine is showing up in your workspace but not in Update Management, you must set the scope configuration to target the machines. To learn about the scope configuration, see Enable machines in the workspace.
Remove the worker configuration by following the steps in Remove the Hybrid Runbook Worker from an on-premises Windows computer or Remove the Hybrid Runbook Worker from an on-premises Linux computer.

Scenario: Superseded update indicated as missing in Update Management

Issue

Old updates are appearing for an Automation account as missing even though they've been superseded. A superseded update is one that you don't have to install because a later update that corrects the same vulnerability is available. Update Management ignores the superseded update and makes it not applicable in favor of the superseding update. For information about a related issue, see Update is superseded.

Cause

Superseded updates aren't declined in Windows Server Update Services (WSUS) so that they can be considered not applicable.

Resolution

When a superseded update becomes 100 percent not applicable, you should change the approval state of that update to Declined in WSUS. To change approval state for all your updates:

In the Automation account, select Update Management to view machine status. See View update assessments.
Check the superseded update to make sure that it's 100 percent not applicable.
On the WSUS server the machines report to, decline the update.
Select Computers and, in the Compliance column, force a rescan for compliance. See Manage updates for VMs.
Repeat the steps above for other superseded updates.
For Windows Server Update Services (WSUS), clean all superseded updates to refresh the infrastructure using the WSUS Server cleanup Wizard.
Repeat this procedure regularly to correct the display issue and minimize the amount of disk space used for update management.

Scenario: Machines don't show up in the portal under Update Management

Issue

Your machines have the following symptoms:

Your machine shows Not configured from the Update Management view of a VM.
Your machines are missing from the Update Management view of your Azure Automation account.
You have machines that show as Not assessed under Compliance. However, you see heartbeat data in Azure Monitor logs for the Hybrid Runbook Worker but not for Update Management.

Cause

This issue can be caused by local configuration issues or by improperly configured scope configuration. Possible specific causes are:

You might have to re-register and reinstall the Hybrid Runbook Worker.
You might have defined a quota in your workspace that's been reached and that's preventing further data storage.

Resolution

Run the troubleshooter for Windows or Linux, depending on the OS.
Make sure that your machine is reporting to the correct workspace. For guidance on how to verify this aspect, see Verify agent connectivity to Azure Monitor. Also make sure that this workspace is linked to your Azure Automation account. To confirm, go to your Automation account and select Linked workspace under Related Resources.
Make sure that the machines show up in the Log Analytics workspace linked to your Automation account. Run the following query in the Log Analytics workspace.
```
Heartbeat
| summarize by Computer, Solutions
```
If you don't see your machine in the query results, it hasn't recently checked in. There's probably a local configuration issue and you should reinstall the agent.

If your machine is listed in the query results, verify under the Solutions property that updates is listed. This verifies it is registered with Update Management. If it is not, check for scope configuration problems. The scope configuration determines which machines are configured for Update Management. To configure the scope configuration for the target the machine, see Enable machines in the workspace.
In your workspace, run this query.
```
Operation
| where OperationCategory == 'Data Collection Status'
| sort by TimeGenerated desc
```
If you get a Data collection stopped due to daily limit of free data reached. Ingestion status = OverQuota result, the quota defined on your workspace has been reached, which has stopped data from being saved. In your workspace, go to data volume management under Usage and estimated costs, and change or remove the quota.
If your issue is still unresolved, follow the steps in Deploy a Windows Hybrid Runbook Worker to reinstall the Hybrid Worker for Windows. For Linux, follow the steps in Deploy a Linux Hybrid Runbook Worker.

Scenario: Unable to register Automation resource provider for subscriptions

Issue

When you work with feature deployments in your Automation account, the following error occurs:

Error details: Unable to register Automation Resource Provider for subscriptions

Cause

The Automation resource provider isn't registered in the subscription.

Resolution

To register the Automation resource provider, follow these steps in the Azure portal.

In the Azure service list at the bottom of the portal, select All services, and then select Subscriptions in the General service group.
Select your subscription.
Under Settings, select Resource Providers.
From the list of resource providers, verify that the Microsoft.Automation resource provider is registered.
If it's not listed, register the Microsoft.Automation provider by following the steps at Resolve errors for resource provider registration.

Scenario: Scheduled update did not patch some machines

Issue

Machines included in an update preview don't all appear in the list of machines patched during a scheduled run, or VMs for selected scopes of a dynamic group are not showing up in the update preview list in the portal.

The update preview list consists of all machines retrieved by an Azure Resource Graph query for the selected scopes. The scopes are filtered for machines that have a system Hybrid Runbook Worker installed and for which you have access permissions.

Cause

This issue can have one of the following causes:

The subscriptions defined in the scope in a dynamic query aren't configured for the registered Automation resource provider.
The machines weren't available or didn't have appropriate tags when the schedule executed.
You don't have the correct access on the selected scopes.
The Azure Resource Graph query doesn't retrieve the expected machines.
The system Hybrid Runbook Worker isn't installed on the machines.

Resolution

Subscriptions not configured for registered Automation resource provider

If your subscription isn't configured for the Automation resource provider, you can't query or fetch information on machines in that subscription. Use the following steps to verify the registration for the subscription.

In the Azure portal, access the Azure service list.
Select All services, and then select Subscriptions in the General service group.
Find the subscription defined in the scope for your deployment.
Under Settings, choose Resource Providers.
Verify that the Microsoft.Automation resource provider is registered.
If it's not listed, register the Microsoft.Automation provider by following the steps at Resolve errors for resource provider registration.

Machines not available or not tagged correctly when schedule executed

Use the following procedure if your subscription is configured for the Automation resource provider, but running the update schedule with the specified dynamic groups missed some machines.

In the Azure portal, open the Automation account and select Update Management.
Check Update Management history to determine the exact time when the update deployment was run.
For machines that you suspect to have been missed by Update Management, use Azure Resource Graph (ARG) to locate machine changes.
Search for changes over a considerable period, such as one day, before the update deployment was run.
Check the search results for any systemic changes, such as delete or update changes, to the machines in this period. These changes can alter machine status or tags so that machines aren't selected in the machine list when updates are deployed.
Adjust the machines and resource settings as necessary to correct for machine status or tag issues.
Rerun the update schedule to ensure that deployment with the specified dynamic groups includes all machines.

Incorrect access on selected scopes

The Azure portal only displays machines for which you have write access in a given scope. If you don't have the correct access for a scope, see Tutorial: Grant a user access to Azure resources using the Azure portal.

Resource Graph query doesn't return expected machines

Follow the steps below to find out if your queries are working correctly.

Run an Azure Resource Graph query formatted as shown below in the Resource Graph explorer blade in Azure portal. If you are new to Azure Resource Graph, see this quickstart to learn how to work with Resource Graph explorer. This query mimics the filters you selected when you created the dynamic group in Update Management. See Use dynamic groups with Update Management.

where (subscriptionId in~ ("<subscriptionId1>", "<subscriptionId2>") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "<Windows/Linux>" and resourceGroup in~ ("<resourceGroupName1>","<resourceGroupName2>") and location in~ ("<location1>","<location2>") )
| project id, location, name, tags = todynamic(tolower(tostring(tags)))
| where  (tags[tolower("<tagKey1>")] =~ "<tagValue1>" and tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "All" option selected for tags
| where  (tags[tolower("<tagKey1>")] =~ "<tagValue1>" or tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "Any" option selected for tags
| project id, location, name, tags

Here is an example:

where (subscriptionId in~ ("aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e", "bbbb1b1b-cc2c-dd3d-ee4e-ffffff5f5f5f") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "Windows" and resourceGroup in~ ("testRG","withinvnet-2020-01-06-10-global-resources-southindia") and location in~ ("australiacentral","australiacentral2","brazilsouth") )
| project id, location, name, tags = todynamic(tolower(tostring(tags)))
| where  (tags[tolower("ms-resource-usage")] =~ "azure-cloud-shell" and tags[tolower("temp")] =~ "temp")
| project id, location, name, tags

Check to see if the machines you're looking for are listed in the query results.
If the machines aren't listed, there is probably an issue with the filter selected in the dynamic group. Adjust the group configuration as needed.

Hybrid Runbook Worker not installed on machines

Machines do appear in Azure Resource Graph query results, but still don't show up in the dynamic group preview. In this case, the machines might not be designated as system Hybrid Runbook workers and thus can't run Azure Automation and Update Management jobs. To ensure that the machines you're expecting to see are set up as system Hybrid Runbook Workers:

In the Azure portal, go to the Automation account for a machine that is not appearing correctly.
Select Hybrid worker groups under Process Automation.
Select the System hybrid worker groups tab.
Validate that the hybrid worker is present for that machine.
If the machine is not set up as a system Hybrid Runbook Worker, review the methods to enable using one of the following methods:
- From your Automation account for one or more Azure and non-Azure machines, including Azure Arc-enabled servers.
- Using the Enable-AutomationSolution runbook to automate onboarding Azure VMs.
- 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.
The method to enable is based on the environment the machine is running in.
Repeat the steps above for all machines that have not been displaying in the preview.

Scenario: Update Management components enabled, while VM continues to show as being configured

Issue

You continue to see the following message on a VM 15 minutes after deployment begins:

The components for the 'Update Management' solution have been enabled, and now this virtual machine is being configured. Please be patient, as this can sometimes take up to 15 minutes.

Cause

This error can occur for the following reasons:

Communication with the Automation account is being blocked.
There is a duplicate computer name with different source computer IDs. This scenario occurs when a VM with a particular computer name is created in different resource groups and is reporting to the same Logistics Agent workspace in the subscription.
The VM image being deployed might come from a cloned machine that wasn't prepared with System Preparation (sysprep) with the Log Analytics agent for Windows installed.

Resolution

To help in determining the exact problem with the VM, run the following query in the Log Analytics workspace that's linked to your Automation account.

Update
| where Computer contains "fillInMachineName"
| project TimeGenerated, Computer, SourceComputerId, Title, UpdateState

Communication with Automation account blocked

Go to Network planning to learn about which addresses and ports must be allowed for Update Management to work.

Duplicate computer name

Rename your VMs to ensure unique names in their environment.

Deployed image from cloned machine

If you're using a cloned image, different computer names have the same source computer ID. In this case:

In your Log Analytics workspace, remove the VM from the saved search for the MicrosoftDefaultScopeConfig-Updates scope configuration if it's shown. Saved searches can be found under General in your workspace.

Run the following cmdlet.

Remove-Item -Path "HKLM:\software\microsoft\hybridrunbookworker" -Recurse -Force

Run Restart-Service HealthService to restart the health service. This operation recreates the key and generates a new UUID.
If this approach doesn't work, run sysprep on the image first and then install the Log Analytics agent for Windows.

Scenario: You receive a linked subscription error when you create an update deployment for machines in another Azure tenant

Issue

You encounter the following error when you try to create an update deployment for machines in another Azure tenant:

The client has permission to perform action 'Microsoft.Compute/virtualMachines/write' on scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/resourceGroupName/providers/Microsoft.Automation/automationAccounts/automationAccountName/softwareUpdateConfigurations/updateDeploymentName', however the current tenant '00000000-0000-0000-0000-000000000000' is not authorized to access linked subscription '00000000-0000-0000-0000-000000000000'.

Cause

This error occurs when you create an update deployment that has Azure VMs in another tenant that's included in an update deployment.

Resolution

Use the following workaround to get these items scheduled. You can use the New-AzAutomationSchedule cmdlet with the ForUpdateConfiguration parameter to create a schedule. Then, use the New-AzAutomationSoftwareUpdateConfiguration cmdlet and pass the machines in the other tenant to the NonAzureComputer parameter. The following example shows how to do this:

$nonAzurecomputers = @("server-01", "server-02")

$startTime = ([DateTime]::Now).AddMinutes(10)

$s = New-AzAutomationSchedule -ResourceGroupName mygroup -AutomationAccountName myaccount -Name myupdateconfig -Description test-OneTime -OneTime -StartTime $startTime -ForUpdateConfiguration

New-AzAutomationSoftwareUpdateConfiguration  -ResourceGroupName $rg -AutomationAccountName $aa -Schedule $s -Windows -AzureVMResourceId $azureVMIdsW -NonAzureComputer $nonAzurecomputers -Duration (New-TimeSpan -Hours 2) -IncludedUpdateClassification Security,UpdateRollup -ExcludedKbNumber KB01,KB02 -IncludedKbNumber KB100

Scenario: Unexplained reboots

Issue

Even though you've set the Reboot Control option to Never Reboot, machines are still rebooting after updates are installed.

Cause

Windows Update can be modified by several registry keys, any of which can modify reboot behavior.

Resolution

Review the registry keys listed under Configuring Automatic Updates by editing the registry and Registry keys used to manage restart to make sure your machines are configured properly.

Scenario: Machine shows "Failed to start" in an update deployment

Issue

A machine shows a Failed to start or Failed status. When you view the specific details for the machine, you see the following error:

For one or more machines in schedule, UM job run resulted in either Failed or Failed to start state. Guide available at https://aka.ms/UMSucrFailed.

Cause

This error can occur for one of the following reasons:

The machine doesn't exist anymore.
The machine is turned off and unreachable.
The machine has a network connectivity issue, and therefore the hybrid worker on the machine is unreachable.
There was an update to the Log Analytics agent that changed the source computer ID.
Your update run was throttled if you hit the limit of 200 concurrent jobs in an Automation account. Each deployment is considered a job, and each machine in an update deployment counts as a job. Any other automation job or update deployment currently running in your Automation account counts toward the concurrent job limit.

Resolution

You can retrieve more details programmatically by using the REST API. See Software Update Configuration Machine Runs for information on retrieving either a list of update configuration machine runs, or a single software update configuration machine run by ID.

When applicable, use dynamic groups for your update deployments. In addition, you can take the following steps.

Verify that your machine or server meets the requirements.
Verify connectivity to the Hybrid Runbook Worker using the Hybrid Runbook Worker agent troubleshooter. To learn more about the troubleshooter, see Troubleshoot update agent issues.

Scenario: Updates are installed without a deployment

Issue

When you enroll a Windows machine in Update Management, you see updates installed without a deployment.

Cause

On Windows, updates are installed automatically as soon as they're available. This behavior can cause confusion if you didn't schedule an update to be deployed to the machine.

Resolution

The HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU registry key defaults to a setting of 4: auto download and install.

For Update Management clients, we recommend setting this key to 3: auto download but do not auto install.

For more information, see Configuring Automatic Updates.

Scenario: Machine is already registered to a different account

Issue

You receive the following error message:

Unable to Register Machine for Patch Management, Registration Failed with Exception System.InvalidOperationException: {"Message":"Machine is already registered to a different account."}

Cause

The machine has already been deployed to another workspace for Update Management.

Resolution

Follow the steps under Machines don't show up in the portal under Update Management to make sure the machine is reporting to the correct workspace.
Clean up artifacts on the machine by deleting the hybrid runbook group, and then try again.

Scenario: Machine can't communicate with the service

Issue

You receive one of the following error messages:

Unable to Register Machine for Patch Management, Registration Failed with Exception System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server can't communicate, because they do not possess a common algorithm

Unable to Register Machine for Patch Management, Registration Failed with Exception Newtonsoft.Json.JsonReaderException: Error parsing positive infinity value.

The certificate presented by the service <wsid>.oms.opinsights.azure.com was not issued by a certificate authority used for Microsoft services. Contact your network administrator to see if they are running a proxy that intercepts TLS/SSL communication.

Access is denied. (Exception form HRESULT: 0x80070005(E_ACCESSDENIED))

Cause

A proxy, gateway, or firewall might be blocking network communication.

Resolution

Review your networking and make sure appropriate ports and addresses are allowed. See network requirements for a list of ports and addresses that are required by Update Management and Hybrid Runbook Workers.

Scenario: Unable to create self-signed certificate

Issue

You receive one of the following error messages:

Unable to Register Machine for Patch Management, Registration Failed with Exception AgentService.HybridRegistration. PowerShell.Certificates.CertificateCreationException: Failed to create a self-signed certificate. ---> System.UnauthorizedAccessException: Access is denied.

Cause

The Hybrid Runbook Worker couldn't generate a self-signed certificate.

Resolution

Verify that the system account has read access to the C:\ProgramData\Microsoft\Crypto\RSA folder, and try again.

Scenario: The scheduled update failed with a MaintenanceWindowExceeded error

Issue

The default maintenance window for updates is 120 minutes. You can increase the maintenance window to a maximum of 6 hours, or 360 minutes. You might receive the error message For one or more machines in schedule, UM job run resulted in Maintenance Window Exceeded state. Guide available at https://aka.ms/UMSucrMwExceeded.

Resolution

To understand why this occurred during an update run after it starts successfully, check the job output from the affected machine in the run. You might find specific error messages from your machines that you can research and take action on.

Edit any failing scheduled update deployments, and increase the maintenance window.

For more information on maintenance windows, see Install updates.

Scenario: Machine shows as "Not assessed" and shows an HRESULT exception

Issue

You have machines that show as Not assessed under Compliance, and you see an exception message below them.
You see an HRESULT error code in the portal.

Cause

The Update Agent (Windows Update Agent on Windows; the package manager for a Linux distribution) isn't configured correctly. Update Management 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 Management can't properly report on the patches that are needed or installed.

Resolution

Try to perform updates locally on the machine. If this operation fails, it typically means that there's an update agent configuration error.

This problem is frequently caused by network configuration and firewall issues. 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 listed in Updates aren't downloading from the intranet endpoint (WSUS/SCCM).
- If the machines are configured for Windows Update, make sure that you can reach the endpoints described in Issues related to HTTP/proxy.
- If the machines are configured for Windows Server Update Services (WSUS), make sure that you can reach the WSUS server configured by the WUServer registry key.

If you see an HRESULT, double-click the exception displayed in red to see the entire exception message. Review the following table for potential resolutions or recommended actions.

Exception	Resolution or action
`Exception from HRESULT: 0x……C`	Search the relevant error code in Windows update error code list to find additional details about the cause of the exception.
`0x8024402C` `0x8024401C` `0x8024402F`	These indicate network connectivity issues. Make sure your machine has network connectivity to Update Management. See the network planning section for a list of required ports and addresses.
`0x8024001E`	The update operation didn't complete because the service or system was shutting down.
`0x8024002E`	Windows Update service is disabled.
`0x8024402C`	If you're using a WSUS server, make sure the registry values for `WUServer` and `WUStatusServer` under the `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate` registry key specify the correct WSUS server.
`0x80072EE2`	There's a network connectivity issue or an issue 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.
`0x80070005`	An access denied error can be caused by any one of the following: Infected computer Windows Update settings not configured correctly File permission error with %WinDir%\SoftwareDistribution folder Insufficient disk space on the system drive (C:).
Any other generic exception	Run a search on the internet for possible resolutions, and work with your local IT support.

Reviewing the %Windir%\Windowsupdate.log file can also help you determine possible causes. For more information about how to read the log, see How to read the Windowsupdate.log file.

You can also download and run the Windows Update troubleshooter to check for any issues with Windows Update on the machine.

Note

The Windows Update troubleshooter documentation indicates that it's for use on Windows clients, but it also works on Windows Server.

Scenario: Update run returns Failed status (Linux)

Issue

An update run starts but encounters errors during the run.

Cause

Possible causes:

Package manager is unhealthy.
Update Agent (WUA for Windows, distro-specific package manager for Linux) is misconfigured.
Specific packages are interfering with cloud-based patching.
The machine is unreachable.
Updates had dependencies that weren't resolved.

Resolution

If failures occur during an update run after it starts successfully, check the job output from the affected machine in the run. You might find specific error messages from your machines that you can research and take action on. Update Management requires the package manager to be healthy for successful update deployments.

If specific patches, packages, or updates are seen immediately before the job fails, you can try excluding these items from the next update deployment. To gather log information from Windows Update, see Windows Update log files.

If you can't resolve a patching issue, make a copy of the /var/opt/microsoft/omsagent/run/automationworker/omsupdatemgmt.log file and preserve it for troubleshooting purposes before the next update deployment starts.

Patches aren't installed

Machines don't install updates

Try running updates directly on the machine. If the machine can't apply the updates, consult the list of potential errors in the troubleshooting guide.

If updates run locally, try removing and reinstalling the agent on the machine by following the guidance at Remove a VM from Update Management.

I know updates are available, but they don't show as available on my machines

This often happens if machines are configured to get updates from WSUS or Microsoft Configuration Manager but WSUS and Configuration Manager haven't approved the updates.

You can check to see if the machines are configured for WSUS and SCCM by cross-referencing the UseWUServer registry key to the registry keys in the Configuring Automatic Updates by Editing the Registry section of this article.

If updates aren't approved in WSUS, they're not installed. You can check for unapproved updates in Log Analytics by running the following query.

Update | where UpdateState == "Needed" and ApprovalSource == "WSUS" and Approved == "False" | summarize max(TimeGenerated) by Computer, KBID, Title

Updates show as installed, but I can't find them on my machine

Updates are often superseded by other updates. For more information, see Update is superseded in the Windows Update Troubleshooting guide.

Installing updates by classification on Linux

Deploying updates to Linux by classification ("Critical and security updates") has important caveats. These limitations are documented on the Update Management overview page.

KB2267602 is consistently missing

KB2267602 is the Windows Defender definition update. It's updated daily.

Next steps

If you don't see your problem or can't resolve your issue, try one of the following channels for additional support.

Get answers from Azure experts through Azure Forums.
Connect with @AzureSupport, the official Microsoft Azure account for improving customer experience.
File an Azure support incident. Go to the Azure support site and select Get Support.

Jaa

Troubleshoot Update Management issues

Scenario: Windows Defender update always show as missing

Issue

Cause

Resolution

Scenario: Linux updates shown as pending and those installed vary

Issue

Cause

Resolution

Scenario: You receive the error "Failed to enable the Update solution"

Issue

Cause

Resolution

Scenario: Superseded update indicated as missing in Update Management

Issue

Cause

Resolution

Scenario: Machines don't show up in the portal under Update Management

Issue

Cause

Resolution

Scenario: Unable to register Automation resource provider for subscriptions

Issue

Cause

Resolution

Scenario: Scheduled update did not patch some machines

Issue

Cause

Resolution

Subscriptions not configured for registered Automation resource provider

Machines not available or not tagged correctly when schedule executed

Incorrect access on selected scopes

Resource Graph query doesn't return expected machines

Hybrid Runbook Worker not installed on machines

Scenario: Update Management components enabled, while VM continues to show as being configured

Issue

Cause

Resolution

Communication with Automation account blocked

Duplicate computer name

Deployed image from cloned machine

Scenario: You receive a linked subscription error when you create an update deployment for machines in another Azure tenant

Issue

Cause

Resolution

Scenario: Unexplained reboots

Issue

Cause

Resolution

Scenario: Machine shows "Failed to start" in an update deployment

Issue

Cause

Resolution

Scenario: Updates are installed without a deployment

Issue

Cause

Resolution

Scenario: Machine is already registered to a different account

Issue

Cause

Resolution

Scenario: Machine can't communicate with the service

Issue

Cause

Resolution

Scenario: Unable to create self-signed certificate

Issue

Cause

Resolution

Scenario: The scheduled update failed with a MaintenanceWindowExceeded error

Issue

Resolution

Scenario: Machine shows as "Not assessed" and shows an HRESULT exception

Issue

Cause

Resolution

Scenario: Update run returns Failed status (Linux)

Issue

Cause