Troubleshooting issues with Update Management

This article discusses solutions to issues that you might encounter when you use Update Management.

There's an agent troubleshooter for the Hybrid Worker agent to determine the underlying problem. To learn more about the troubleshooter, see Troubleshoot update agent issues. For all other issues, use the following troubleshooting guidance.

If you encounter issues while you're trying to onboard the solution on a virtual machine (VM), check the Operations Manager log under Application and Services Logs on the local machine for events with event ID 4502 and event details that contain Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent.

The following section highlights specific error messages and possible resolutions for each. For other onboarding issues see Troubleshoot solution onboarding.

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


You experience 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.


This issue can be caused by local configuration issues or by improperly configured scope configuration.

You might have to reregister 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.


  • Run the troubleshooter for Windows or Linux, depending on the OS.

  • Make sure your machine is reporting to the correct workspace. For guidance on how to verify this aspect, see Verify agent connectivity to Log Analytics. Also make sure 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 the machines show up in your Log Analytics workspace. Run the following query in the Log Analytics workspace that's linked to your Automation account:

    | summarize by Computer, Solutions

    If you don't see your machine in the query results, it hasn't recently checked in, which means there's probably a local configuration issue and you should reinstall the agent. If your machine shows up in the query results, you need to verify the scope configuration specified in the next bulleted item in this list.

  • Check for scope configuration problems. Scope configuration determines which machines get configured for the solution. If your machine is showing up in your workspace but not in the Update Management portal, you'll need to configure the scope configuration to target the machines. To learn how to do this, see Onboard machines in the workspace.

  • In your workspace, run the following query:

    | 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, there's a quota defined on your workspace that's been reached and that has stopped data from being saved. In your workspace, go to Usage and estimated costs > data volume management and check your quota or remove it.

  • If these steps don't resolve your problem, follow the steps at Deploy a Windows Hybrid Runbook Worker to reinstall the Hybrid Worker for Windows. Or, for Linux, deploy a Linux Hybrid Runbook Worker.

Scenario: Unable to register Automation Resource Provider for subscriptions


When you work with solutions in your Automation account, you encounter the following error:

Error details: Unable to register Automation Resource Provider for subscriptions:


The Automation Resource Provider isn't registered in the subscription.


To register the Automation Resource Provider, follow these steps in the Azure portal:

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

Scenario: The components for the Update Management solution have been enabled, and now this virtual machine is being configured


You continue to see the following message on a virtual machine 15 minutes after onboarding:

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.


This error can occur for the following reasons:

  • Communication with the Automation account is being blocked.
  • The VM being onboarded might have come from a cloned machine that wasn't sysprepped with the Microsoft Monitoring Agent (MMA) installed.


  1. Go to Network planning to learn about which addresses and ports must be allowed for Update Management to work.
  2. If you're using a cloned image:
    1. 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.
    2. Run Remove-Item -Path "HKLM:\software\microsoft\hybridrunbookworker" -Recurse -Force.
    3. Run Restart-Service HealthService to restart the HealthService. This recreates the key and generates a new UUID.
    4. If this approach doesn't work, run sysprep on the image first and then install the MMA.

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


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/00000000-0000-0000-0000-000000000000/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'.


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


Use the following workaround to get these items scheduled. You can use the New-AzureRmAutomationSchedule cmdlet with the -ForUpdate switch to create a schedule. Then, use the New-AzureRmAutomationSoftwareUpdateConfiguration 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-AzureRmAutomationSchedule -ResourceGroupName mygroup -AutomationAccountName myaccount -Name myupdateconfig -Description test-OneTime -OneTime -StartTime $startTime -ForUpdate

New-AzureRmAutomationSoftwareUpdateConfiguration  -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


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


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


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


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

Failed to start the runbook. Check the parameters passed. RunbookName Patch-MicrosoftOMSComputer. Exception You have requested to create a runbook job on a hybrid worker group that does not exist.


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 MMA that changed the SourceComputerId.
  • Your update run was throttled if you hit the limit of 2,000 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.


When applicable, use dynamic groups for your update deployments. Additionally:

  • Verify that the machine still exists and is reachable. If it doesn't exist, edit your deployment and remove the machine.

  • See the network planning section for a list of ports and addresses that are required for Update Management, and then verify that your machine meets these requirements.

  • Run the following query in Log Analytics to find machines in your environment whose SourceComputerId has changed. Look for computers that have the same Computer value but a different SourceComputerId value.

    Heartbeat | where TimeGenerated > ago(30d) | distinct SourceComputerId, Computer, ComputerIP

    After you find affected machines, edit the update deployments that target those machines, and then remove and re-add them so that SourceComputerId reflects the correct value.

Scenario: Updates are installed without a deployment


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


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.


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


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."}


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


  1. 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.
  2. Clean up old artifacts on the machine by deleting the hybrid runbook group, and then try again.

Scenario: Machine can't communicate with the service


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> 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))


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


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


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.


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


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


The default maintenance window for updates is 120 minutes. You can increase the maintenance window to a maximum of 6 hours, or 360 minutes.


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


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


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.


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

This problem is frequently caused by network configuration and firewall issues. Try the following:

If you see an HRESULT, double-click the exception displayed in red to see the entire exception message. Review the following table for potential solutions 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.
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 solutions, 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.


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)


An update run starts but encounters errors during the run.


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.


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 those from the next update deployment. To gather log info from Windows Update, see Windows Update log files.

If you can't resolve a patching issue, make a copy of the following log file and preserve it for troubleshooting purposes before the next update deployment starts:


Patches aren't installed

Machines don't install updates

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

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, especially for CentOS. These limitations are documented on the Update Management overview page.

KB2267602 is consistently missing

Next steps

If you didn'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 by connecting the Azure community to the right resources: answers, support, and experts.
  • File an Azure support incident. Go to the Azure support site and select Get Support.