Skip to main content

SCCM WSUS WCM.log - System.Net.WebException: The request failed with HTTP status 404

System.Net.WebException: The request failed with HTTP status 404: Not Found.~~   at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)~~   at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber)

Overview:

I was recently working with a customer who was receiving a HTTP 404 error in the WCM.log.

  • Confirmed the following ports are open (80,443,135,445,8530,8531)
  • WSUS sites are accessible via URL HTTP
  • Boundaries and Boundary groups for content and site assignment are configured correctly for DEV domain.
  • Distribution Point and Management Point roles are fully functionality
  • WSUS on Server2.dev.local manually synchronized from the Internet
  • Remote Registry and remote WMI tested with success.

Lab Environment Expected behaviour:

In my lab environment I have two forests/domains “Contoso.local” and “DEV20.local”; untrusted; Windows firewall ON with default values.

  • I have added the Site System server role (SUP) to Dev20.local  with a “WSUS Server Connection Account” (DEV20\LabAdmin).
  • In the WCM.log (Fig1) you can see the successful connection to the dev2 server. Once this connection is made the WSUS installation is configured as a downstream server and the site will synchronize.
  • Wireshark (Fig2) reveals the connection address, Src +Dst Ports, and the authentication negotiation between the domains and importantly a success connection.
  • I have not been able to recreate the “System.Net.WebException: The request failed with HTTP status 404: Not Found” error within my lab most likely due to the specific infrastructure setup at Client site  (Proxy, Firewall rules) 


Fig 1

Fig 2
Solution:
Remove the Proxy configurations from both the Site Server and Site System. While the site may not Synchronize with Microsoft Update servers, it will still allow connectivity between the Site Server and the Site System. Restart the SMS_Executive Service and review the WCM.log

This proved that the issue at the client site was Proxy related. Sounds like the proxy bypass rules in IE don't seem to apply to the SCCM proxy configuration. dev.local lookups should bypass the proxy.
Client to check rules on the proxy that can intercept traffic bound for non port 80/443 ports and forward accordingly (external sites on random ports). Client to intercept the dev.local traffic on the Proxy server and forward from the DMZ back into dev.local



Comments

  1. During Norton Setup at norton.com/setup, Product key is very essential. To get the Norton Product key, scratch off the silver layer in the back of the retail card and preserve it geared up earlier than start the Norton setup. Here is a sample of Product key to make you understand: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX.
    http://i-nortonnorton.com/

    ReplyDelete

Post a Comment

Popular posts from this blog

Windows 7 Offline files will not go Online when connected to network

Issue Several laptop users move between networks, domain, home, etc and when they attempt to access DFS shares explorer status is working offline.  The issue only resolves it self after a reboot. Connecting directly to the share works and i am able to ping network resources.  This behavior occurs for VPN users as well. Possible Causes "slow-link mode". In win7 (with default settings) a client will enter slow-link mode if the latency to the server is above 80ms. In slow-link mode all writes are made to the local cache and a background sync only happens every 6 hours.  Depending on your connection the default slow link detection speed is 64,000 bps On client computers running Windows 7 or Windows Server 2008 R2, a shared folder automatically transitions to the slow-link mode if the round-trip latency of the network is greater than 80 milliseconds, or as configured by the "Configure slow-link mode" policy. After transitioning a folder to the slow-link mode, Offline Fil

SCCM Unknown computer not able to see Task Sequences after installing Current Branch 1702

Soon after installing SCCM CB 1702 we were unable to see Task Sequences deployed to the unknown collection. This issue was identified as a random system taking the GUID of the 'x64 Unknown Computer (x64 Unknown Computer)' record. As a result it was now a known GUID; as we were only deploying Task Sequences to the Unknown collection none were made available. 'x64 Unknown Computer (x64 Unknown Computer)' record 'x86 Unknown Computer (x86 Unknown Computer)' record To get the GUID of your unknown systems open SQL management studio and run the following command: --Sql Command to list the name and GUID for UnknownSystems record data select ItemKey, Name0,SMS_Unique_Identifier0 from UnknownSystem_DISC Using the returned GUID (SMS_Unique_Identifier0) we can find the hostname that has been assigned the 'x64 Unknown Computer (x64 Unknown Computer)' GUID by running the query below. --x64 Unknown Computers select Name0,SMS_Unique_Identifier0,Decommissioned0 from Sys

SCCM Client Certificate (PKI) Value is None

SCCM Client Certificate (PKI) Value is None Symptoms: Are you seeing the following errors logged? ClientIDManagerStartup.log - Error: 0x87d00231 [RegTask] - Client is not registered. Sending registration request for GUID:12345678...98C1AE ... RegTask: Failed to send registration request message. Error: 0x87d00231 ClientIDManagerStartup RegTask: Failed to send registration request. Error: 0x87d00231 ClientIDManagerStartup LocationServices.log Failed to send management point list Location Request Message to SiteServer.Domain.local 1 assigned MP errors in the last 10 minutes, threshold is 5. CcmMessaging.log Status Agent hasn't been initialized yet. Attempting to create pending event. Successfully queued event on HTTP/HTTPS failure for server 'SiteServer.Domain.local'. Post to https://SiteServer.Domain.local/ccm_system_windowsauth/request failed with 0x87d00231. Failed to open to WMI namespace '\\.\root\ccm' (80041003) Failed in WinHtt