Device Not Compatible - Cannot Connect to Windows Update Server

Issue

A Windows device fails to scan or patch, and the Activity Log or the Windows Event Viewer shows that Windows Update cannot reach an update server. Typical signals include:

• Errors such as 0x8024401c (request to the update server timed out), 0x80244022 (server returned HTTP 502/503), 0x80240438 (the configured update endpoint is unreachable), or 0x8024002E (the update server denied access).
• 0x80070422, which means the Windows Update service is disabled or misconfigured on the device.
• The device showing few or no applicable updates in Automox even though updates are expected.

The underlying cause is almost always that the device cannot talk to the update source Windows Update is pointed at — either an internal WSUS/SCCM server or Microsoft Update on the internet.

Environment

• Automox (current agent release)
• Windows devices running Windows Update scans/patch policies
• Console areas: Activity Log, device Software page
• Devices in environments that use WSUS/SCCM, a proxy, or a filtering firewall

Overview

Automox does not run its own update catalog on Windows. It drives the built-in Windows Update Agent (WUA) on each device, so Automox reports whatever WUA reports. If a Group Policy (GPO) or MDM profile points WUA at a WSUS/SCCM server (the UseWUServer / WUServer registry settings), the device scans that server — not Microsoft Update — regardless of Automox's intent. When that server is unreachable, has not approved the expected updates, or the device is blocked from reaching Microsoft Update directly, the scan fails or returns nothing, and the errors above appear.

There are three common branches:

1. Device pointed at an unreachable or out-of-sync WSUS/SCCM server (via GPO/MDM).
2. A proxy, firewall, or TLS-inspection appliance blocking access to Microsoft Update.
3. A "dual scan" / managed-updates conflict, where WSUS management and direct Microsoft Update both apply and fight over the device.

Resolution

1. Confirm the Windows Update services are enabled and running (fixes 0x80070422):
   • In services.msc, set Windows Update (wuauserv) and Background Intelligent Transfer Service (bits) to Automatic (or Manual/Trigger Start for wuauserv) and start them.
   • If the services will not start or the error persists, run the Windows Update Services Reset.
2. Determine what update source the device is actually using:
   • Follow WSUS: Troubleshooting and Best Practices to identify the winning GPO and read the HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate keys. The UseWUServer value is the decisive one — 1 means the device is bound to WSUS/SCCM, not Microsoft Update.
   • Generate the decoded update log with Get-WindowsUpdateLog and check which server the device contacted in the scan-source lines.
3. If the device is bound to WSUS/SCCM (branch 1):
   • Confirm the WSUS/SCCM server is reachable from the device and that the expected updates are approved and synced on that server. A device correctly reports zero applicable updates when its WSUS catalog has not approved them — this is a server-side gap, not an Automox fault.
   • If the device should patch directly from Microsoft Update instead, remove the WSUS/SCCM GPO or MDM setting so WUA is no longer redirected, then reset the update components with the Windows Update Services Reset and rescan.
4. If the device should reach Microsoft Update but a proxy/firewall is blocking it (branch 2 — 0x8024401c, 0x80244022):
   • Ensure the device can reach the Microsoft Update endpoints (for example *.windowsupdate.com, *.delivery.mp.microsoft.com, *.update.microsoft.com) through any proxy or TLS-inspection appliance.
   • Confirm the WinHTTP proxy the SYSTEM account uses with netsh winhttp show proxy; a user-level proxy is not enough because WUA runs as SYSTEM.
5. If both WSUS management and direct updates apply (branch 3 — "dual scan" conflict):
   • Decide on a single update source. Running WSUS-managed policies alongside direct Automox/Microsoft Update patching causes updates to conflict and fail; align the GPO/MDM configuration to one source and rescan.
6. Rescan the device from the Automox Console and re-run the policy to confirm the connection is restored and updates are detected. For interpreting other codes seen along the way, use the Microsoft Windows Update error reference and Common Windows Update Error Codes.

Notes

• Automox uses WSUS when the device is configured to use WSUS. It cannot override a GPO or MDM policy that redirects the Windows Update Agent — that configuration is controlled on the customer side.
• A device reporting no applicable updates is not always a failure. When the device is WSUS-bound and its server has not approved the current month's updates, "0 updates" is the correct result; approve/sync them on the WSUS/SCCM side.
• On Windows 10/11 the raw WindowsUpdate.log is not human-readable. Use Get-WindowsUpdateLog to decode it before analyzing.
• WSUS/SCCM leftovers can persist after a device is supposed to have moved off internal management, redirecting scans to an internal server that no longer answers (0x80240438). Clearing the WSUS registry settings and resetting the update components resolves this.