An Azure service to centrally manages updates and compliance at scale.
Hello Mohamad Irsyad,
Thank you for reaching out to the Microsoft Q&A forum.
When investigated you it looks like your Arc-enabled Windows Server 2019 is throwing HResult 0x80072efe, which generally means the Windows Update Agent can’t reach its update endpoint (a timeout). Since you’ve got another VM in the same network/proxy that works, let’s focus on the Windows Update agent, network and extension logs:
You can try below options.
- Verify Windows Update works locally
- On the problem server, open an elevated PowerShell or CMD and run:
-
net start wuauserv -
wuauclt /detectnow(or “Get-WindowsUpdateLog” on Server 2016+) - Check WindowsUpdate.log (
C:\Windows\Logs\WindowsUpdate\WindowsUpdate.log) and CBS.log (%windir%\Logs\CBS) for any 0x80072efe entries.
- Confirm WSUS vs Microsoft Update settings
- If you use WSUS, open regedit and inspect HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
- Are WUServer/WUStatusServer pointing to the right host? • Can you ping/telnet to that server/port?
- If you’re using direct Microsoft Update, verify your proxy settings under IE/WinHTTP:
-
netsh winhttp show proxy - Adjust with netsh winhttp set proxy if needed.
- Review the Arc patch extension logs
-
C:\ProgramData\GuestConfig\extension_logs\Microsoft.SoftwareUpdateManagement.WindowsOsUpdateExtension<version>\telemetryLogs - WindowsUpdateExtension.log
-
cmd_execution__stdout.txt / stderr.txt - Look for network- or timeout-related errors right before the 0x80072efe.
-
- Check the Arc agent & extension status in Azure
- In the Azure portal, go to your Arc machine and verify the guest agent’s health (should be “Ready” and “Connected”).
- Use the built-in diagnostics under Update Manager: • Patch Mode Diagnostic • Agent Status (Arc VM) • Disconnected Arc Machine
- Confirm Periodic Assessment is enabled in your update settings (otherwise manual “Check for updates” is your only path).
- Compare with the working server
- Run the same manual Windows Update steps and proxy/WSUS tests.
- Compare registry, “netsh winhttp” output, firewall rules, and extension versions.
If the issue still exists, kindly answer below questions for further investigation
- Does “wuauclt /detectnow” or the Windows Update GUI download updates successfully on that server?
- Are you pointing to a WSUS server or using public Windows Update?
- What does “netsh winhttp show proxy” return on the failing VM vs the working one?
- Can you successfully reach the update endpoint URLs in the documentation (e.g. via IE or curl)?
- Any differences in the Arc extension version or guest agent version between the two servers?
- Have you checked those extension logs for a more detailed error stack?
Reference docs
- Troubleshoot machine “Not assessed” and HRESULT errors: https://aka.ms/TroubleshootVMGuestPatching
- Network & proxy requirements for Windows Update: https://aka.ms/WindowsUpdateHTTPProxy
- Arc VM extension troubleshooting: https://learn.microsoft.com/azure/azure-arc/servers/troubleshoot-vm-extensions
- Configure Windows Update Agent: https://learn.microsoft.com/azure/update-center/configure-wu-agent
- Enable periodic assessment & manage update settings: https://learn.microsoft.com/azure/update-manager/manage-update-settings
- Support matrix & prerequisites: https://learn.microsoft.com/azure/update-manager/support-matrix
Let me know if any further queries - feel free to reach out!