This article explains how Atera gets its Windows patch list from the Windows Update Agent (WUA) API, why that list can differ from Windows Update history on the device, how to clear the agent's patch cache when patches in Atera don't match the device, which Microsoft servers to allow, and where to find logs when a Windows update fails with an error.

Microsoft WUA API

Atera is fully aligned with Microsoft WUA (Windows Update Agent) and fetches the available patches list using the WUA API. More details from Microsoft

Therefore, results in Atera should not be matched with results from Windows Update History.

Below are the commands provided by Microsoft to use with their WUA API. Based on these commands, Atera fetches the available and installed list of patches that you see in the console. Both commands create a Microsoft.Update.Session object and search for updates: IsInstalled=1 lists installed patches, and IsInstalled=0 lists available patches.

PowerShell script for installed patches:

$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = $Session.CreateUpdateSearcher()
$Searcher.Search("IsInstalled=1").Updates | ft -a title

PowerShell script for available patches:

$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = $Session.CreateUpdateSearcher()
$Searcher.Search("IsInstalled=0").Updates | ft -a title

Clear the Agent's Patch Cache When Patches in Atera Don't Match the Device

If the patches shown in Atera still don't match the device after a refresh, clear the agent's patch cache. Delete the file ptc3.cch from C:\Program Files\ATERA Networks\AteraAgent\Agent\packages\AgentPackageOsUpdates, then restart the AteraAgent service. You can do both from a command prompt with these commands:

del "C:\Program Files\ATERA Networks\AteraAgent\Agent\packages\AgentPackageOsUpdates\ptc3.cch"
net stop "AteraAgent" && net start "AteraAgent"

Server List

Here's a list of optional Microsoft servers that can enhance the functionality of Atera's patch management module. Allowing these servers on your network is recommended for optimal performance.

• windowsupdate.microsoft.com
• *.windowsupdate.microsoft.com
• *.update.microsoft.com
• *.windowsupdate.com
• download.windowsupdate.com
• *.download.windowsupdate.com
• download.microsoft.com
• wustat.windows.com
• ntservicepack.microsoft.com
• stats.microsoft.com
• fe3cr.delivery.mp.microsoft.com

Note: Allow outbound traffic access to ports 80 and 443 on the above domains.

Maximum Download Size

The Windows Update Agent API uses two values for a patch size: MinDownloadSize and MaxDownloadSize. The agent calculates the maximum potential installation size. For a cumulative patch, the maximum potential size takes into account the data for all possible OS builds compatible with the patch. On a single device, the full size should only be a few GBs.

This is based on the following PowerShell query, which runs the available patches search (IsInstalled=0) and lists each patch's title and maxdownloadsize:

$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = $Session.CreateUpdateSearcher()
$Searcher.Search("IsInstalled=0").Updates | ft -a title, maxdownloadsize

Note: The MinDownloadSize property of an update is always downloaded. However, the MaxDownloadSize property is not always downloaded. The MaxDownloadSize property is downloaded based on the configuration of the computer that receives the update.

If you cannot install an update because your device is running low on free space, follow this Microsoft troubleshooting guide.

Patch Release Date

You can find a patch's release date in Atera by accessing the Device page > Manage > Patch Management > filter Installed Patches - Yes.

This date is the LastDeploymentChangeTime, which is the last published date of the update, in Coordinated Universal Time (UTC), on the server that deploys the update.

It is based on the following script, which runs the installed patches search (IsInstalled=1) and lists each patch's title and lastdeploymentchangetime:

$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = $Session.CreateUpdateSearcher()
$Searcher.Search("IsInstalled=1").Updates | ft -a title, lastdeploymentchangetime

Troubleshoot General Windows Update Errors

Patching a machine either through Atera or using the local Windows Update service can return various errors.

Windows Update error codes, such as 0x80244022, 0x8024402C, 0x8024001E, 0x80072EE2, 0x80240FFF, and 0x80240024, come from Windows Update on the device. Atera only reports the error that Windows returns, so the cause has to be investigated on the device itself.

The first troubleshooting step is finding out more details on the error. Check the following logs, depending on how the patching was run:

• Atera patching: a log.txt is saved by default in C:\Program Files\ATERA Networks\AteraAgent\Agent\packages\AgentPackageOsUpdates
• Local Windows patching: read the logs using the PowerShell command Get-WindowsUpdateLog (applicable to Windows 10)

Once you locate the error, refer to this Microsoft guide for Windows Update common errors and mitigation or search online for suggested fixes.

For a list of the most common errors returned by the Patch & Automation Feedback report, see Understanding the Patch & Automation Feedback Report.

You can also use this Microsoft guide to troubleshoot problems updating Windows 10 (for Windows 8.1 and 7, see Fix Windows Update errors).

Reset Windows Update Components

A full reset of the Windows Update services, files, and folders can also help resolve Windows Update errors. Two scripts posted by Microsoft Script Center users are listed in Microsoft's additional resources for Windows Update.

Note: Although the scripts have been tested in different OS environments, test them on a lab machine before deployment.