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

Popular posts from this blog

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...

KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932

This article outlines the protection against the publicly disclosed Secure Boot security feature bypass involving the BlackLotus UEFI bootkit (CVE-2023-24932). It includes steps to enable the necessary mitigations and provides guidance on creating bootable media. I will provide: - An overview of the CVE issue. - Pre-requisite actions within ADK. - Detection and remediation scripts for CVE-2023-24932. - Instructions for creating a WinPE Boot.wim file to support systems that have undergone remediation. - A breakdown of the files changed and how to boot WinPE to support systems before remediation. 1. Secure Boot Security Feature Bypass Vulnerability CVE-2023-24932 see MSRC CVE-2023-24932 is a security vulnerability involving the BlackLotus UEFI bootkit, which allows attackers to bypass Secure Boot protections. This vulnerability enables the execution of malicious code at the UEFI level, potentially leading to persistent and evasive threats. Mitigations for this issue include updates to th...

Java 7 update 21 (1.7.0_21) Enterprise Repackaged Security Medium Deployment with SCCM

------------------------------------------------------------------------------------------------- Java 7 update 45 Enterprise deployment complete walk through http://www.syswow64.co.uk/2013/10/java-7-update-45-enterprise-deployment.html -------------------------------------------------------------------------------------------------- The issue on many blogs and articles is around creating the 'deployment.config' and 'deployment.properties' files for an enterprise deployment.  In my case i wanted to set the security level to 'Medium', but everytime I open the Java control panel it was set to the default HIGH setting. Solution 1 Create the following directory path 'C:\Windows\sun\java\deployment' 2 Create a file called 'deployment.config' in this directory and open with Notepad. Copy the two line below #################### deployment.system.config = file\:\\C\:\\WINDOWS\\Sun\\Java\\Deployment\\deployment.properties deployment.system...