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.
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
Post a Comment