Share via

windows server 2022 updates fails on VM in OCI

Adrian Neacsu 20 Reputation points
2026-05-11T17:41:37.1466667+00:00

hello,

i provisioned a windows 2022 server VM in OCI for a pipeline project; it has connectivity via a proxy, but for windows updates i added a local group policy to add an url for download; this url is also used in other tenancies; the problem is that the client does not reach the url; policy looks good from reg edit perspective;policy.png

url is reachable from curl/browser; but is not used by client update;

i paste here the first lines of logs from windows updates; as you can see there is an error 80041002, and then WSUS server: (null) - here we should see the url provided in policy; (i forced the update after policy changed, restart machine, etc);

proxy is set up for system wide and for current user logged in; it bypasses the WSUS url, since is an internal IIS server used for updates; i also see the TCP ip6 is enabled on the VM;

i tried various things but no luck;

any idea, what i should do next?

thanks,

Adrian

2026/05/08 06:17:11.6705704 5012 5040 Shared * START * Service startup 2026/05/08 06:17:11.9331492 5012 5040 Shared InitializeSus 2026/05/08 06:17:11.9391790 5012 5040 IdleTimer Non-AoAc machine. Aoac operations will be ignored. 2026/05/08 06:17:11.9393664 5012 5040 Agent WU client version 10.0.20348.5020 2026/05/08 06:17:11.9395674 5012 5040 Agent SleepStudyTracker: Machine is non-AOAC. Sleep study tracker disabled. 2026/05/08 06:17:11.9396405 5012 5040 Agent Base directory: C:\Windows\SoftwareDistribution 2026/05/08 06:17:11.9635226 5012 5040 Agent Datastore directory: C:\Windows\SoftwareDistribution\DataStore\DataStore.edb 2026/05/08 06:17:11.9867752 5012 5040 DataStore JetEnableMultiInstance succeeded - applicable param count: 5, applied param count: 5 2026/05/08 06:17:12.8056463 5012 5040 DataStore Service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 added 2026/05/08 06:17:12.8488528 5012 5040 DataStore Service 9482F4B4-E343-43B6-B170-9A65BC822C77 added 2026/05/08 06:17:12.8506109 5012 5040 DataStore Data store successfully created 2026/05/08 06:17:12.8542045 5012 5040 Shared UpdateNetworkState Ipv6, cNetworkInterfaces = 0. 2026/05/08 06:17:12.8543729 5012 5040 Shared UpdateNetworkState Ipv4, cNetworkInterfaces = 1. 2026/05/08 06:17:12.8554756 5012 5040 Shared Network state: Connected 2026/05/08 06:17:14.4383859 5012 5040 Agent FAILED [80041002] file = onecore\enduser\windowsupdate\client\lib\util\wbemutil.cpp, line = 58 2026/05/08 06:17:14.4428907 5012 5040 Agent Created new random SusClientId 1c3368fb-2ac6-4690-b877-3da83a2fce09. Old Id: none. 2026/05/08 06:17:14.6068724 5012 5040 DownloadManager Deleted install directory C:\Windows\SoftwareDistribution\Download\Install 2026/05/08 06:17:14.7617295 5012 5040 DownloadManager DownloadJobManager init 2026/05/08 06:17:14.8460934 5012 1484 Agent Initializing global settings cache 2026/05/08 06:17:14.8460956 5012 1484 Agent WSUS server: (null) 2026/05/08 06:17:14.8460966 5012 1484 Agent WSUS status server: (null) 2026/05/08 06:17:14.8460975 5012 1484 Agent Alternate Download Server: (null) 2026/05/08 06:17:14.8460985 5012 1484 Agent Fill Empty Content Urls: No 2026/05/08 06:17:14.8460992 5012 1484 Agent Target group: (Unassigned Computers) 2026/05/08 06:17:14.8460999 5012 1484 Agent Windows Update access disabled: No 2026/05/08 06:17:14.8461007 5012 1484 Agent Do not connect to Windows Update Internet locations: No 2026/05/08 06:17:14.8484056 5012 5040 Shared UpdateNetworkState Ipv6, cNetworkInterfaces = 0. 2026/05/08 06:17:14.8484585 5012 5040 Shared UpdateNetworkState Ipv4, cNetworkInterfaces = 1. 2026/05/08 06:17:14.8484939 5012 5040 Shared Power status changed 2026/05/08 06:17:14.8731487 5012 1484 Agent Initializing Windows Update Agent 2026/05/08 06:17:14.8732540 5012 1484 DownloadManager Download manager restoring 0 downloads

Windows for business | Windows Server | Devices and deployment | Install Windows updates, features, or roles
0 comments

Answer accepted by question author

VPHAN 33,510 Reputation points Independent Advisor
2026-05-12T09:05:52.41+00:00

Hi Adrian Neacsu Good progress on clearing out the redundant registry key. The 80070057 error you are seeing now translates directly to an "invalid parameter" exception. In the context of your logs, this means the underlying Windows Update background service is completely rejecting the formatting of your imported proxy bypass list.

The culprit here is the 127.0.0.1/8 entry. While standard browsers and their underlying framework will happily process or ignore CIDR subnet notation, the stricter WinHTTP framework utilized by Windows Update does not support it at all. The moment WinHTTP attempts to parse the slash character for an IP range, it flags the entire bypass string as structurally malformed and immediately aborts the web service call before even attempting to reach your internal WSUS server.

To resolve this, you need to strip out any CIDR formatting. Instead of relying on the IE import command, set the system proxy directly from your elevated command prompt. You can use the command netsh winhttp set proxy proxy-server="1.2.3.4:80" bypass-list=".eng-ABC-vcn.com;localhost;127." to explicitly define your environment using standard wildcards. Make sure to audit the rest of your bypass list for any other slash notations, replace them with asterisks, and then restart the Windows Update service to force it to read the new configuration.

VPHAN

Was this answer helpful?

1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 33,510 Reputation points Independent Advisor
    2026-05-11T18:23:11.1533333+00:00

    Hi Adrian Neacsu,

    The primary reason your client is ignoring the update URL and logging a null WSUS server is the placement of your registry values. The UseWUServer DWORD must be located inside an AU subkey beneath the WindowsUpdate key, rather than directly inside the WindowsUpdate key itself. You will need to right-click the WindowsUpdate folder in the registry editor's left pane, create a new key named AU, and then recreate the UseWUServer DWORD with a value of 1 inside that new AU folder. Once placed in the correct path, the update agent will stop returning a null value and properly recognize your WUServer and WUStatusServer URLs.

    The 80041002 error in your logs means a missing WMI object, and points to corruption in the Windows Management Instrumentation repository preventing the update agent from initializing. Rather than completely renaming or deleting the repository folder, you should safely repair it. Open an elevated command prompt and run the command winmgmt /salvagerepository, which will verify and automatically rebuild the database structure without removing your existing WMI classes.

    It;s important to remember that the Windows Update Agent runs as the background SYSTEM account and usually ignores user-level browser proxies. In your elevated command prompt, running netsh winhttp import proxy source=ie will force the system-level HTTP services to inherit your current user proxy and bypass configurations. After making these registry and proxy corrections, stop the Windows Update service, delete the contents of the C:\Windows\SoftwareDistribution folder to flush out the old cache, and restart your server to apply a clean update state.

    Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

    VPHAN

    Was this answer helpful?

  2. AI answer

    2026-05-11T17:42:07.8566667+00:00

    The Windows Update client log shows that no WSUS server configuration is being picked up:

    WSUS server: (null) WSUS status server: (null)

    This means the local policy/registry settings that should point to the WSUS URL are either not applied in the context that the Windows Update Agent uses, or are overridden/misconfigured.

    Use the following checks and steps:

    1. Verify which update source the client sees
      1. Open PowerShell as Administrator.
      2. Run: 
              $MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
      $MUSM.Services
      3. Confirm whether Windows Server Update Service - OffersWindowsUpdates: True appears. If not, the WSUS configuration is not active on the client.
    2. Confirm WSUS policy is applied in the correct scope
      1. If using Local Group Policy, open gpedit.msc → Computer Configuration → Administrative Templates → Windows Components → Windows Update → Manage updates offered from Windows Server Update Service.
      2. Ensure Specify intranet Microsoft update service location is Enabled and both:
        • Set the intranet update service for detecting updates and
        • Set the intranet statistics server are set to the same WSUS URL (for example http://wsusserver:8530).
      3. Run gpupdate /force and then restart the VM.
      4. After reboot, check the registry at: 
              HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
      HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
        and confirm values like WUServer, WUStatusServer, and UseWUServer are present and correct.
    3. Ensure the environment is not in a “bad setup” state If the client is configured to use WSUS but WSUS has no approved updates or is misconfigured, scans can succeed but never show updates. In such cases, logs show scans with no deployment action from the server. Make sure:
      • The WSUS server actually has Windows Server 2022 updates synchronized.
      • Updates are approved for the computer group that this VM belongs to.
      • If Configuration Manager is not in use, only WSUS approval controls what the client can install.
    4. Check for proxy-related issues Even though the WSUS URL is internal and bypassed, proxy misconfiguration can still block the Windows Update Agent, which uses WinHTTP:
      1. On the VM, run: 
              netsh winhttp show proxy
        and verify the proxy and bypass list are correct for the WSUS FQDN.
      2. If Internet Explorer/Edge proxy is correct, import it to WinHTTP: 
              netsh winhttp import proxy source=ie
      3. Confirm the proxy does not require user authentication for the WSUS URL and that the VM can reach the WSUS server by FQDN and port (80/8530 or 443/8531) without TLS/HTTP mismatch.
    5. Validate network access to update endpoints (if using Windows Update Online) If the intent is to use Windows Update online instead of WSUS, ensure the device can reach the required Windows Update endpoints and that firewall/NVA rules allow HTTP/HTTPS/TLS 1.2 as required. If WSUS is configured, the client will not use Windows Update online unless policy allows it.
    6. Review the 0x80041002 entry The *FAILED* [80041002] ... wbemutil.cpp entry indicates a WMI-related issue early in initialization, but the log continues and the agent starts. Focus first on getting the WSUS configuration visible (non-null) in the log; if problems persist after WSUS is correctly detected, then investigate WMI health.
    7. Re-run a scan and re-check logs After fixing policy and proxy:
      1. Run wuauclt /detectnow or usoclient StartScan (depending on OS support).
      2. Check %windir%\logs\windowsupdate for new entries and confirm that WSUS server: now shows the configured URL and that no proxy/TLS errors are logged.

    If after these steps the WSUS URL still shows as (null) in the log, the priority is to re-validate the Local Group Policy configuration and ensure no higher-level domain GPO or conflicting registry setting is clearing or overriding the WSUS keys.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.