I had an interesting case a few weeks back. I was on-site going over various aspects of SCCM with a customer and we wanted to do some patch deployments in their test lab, which they previously setup. I quickly became aware that many of their clients were not communicating with the WSUS machine to scan for updates. After a little troubleshooting we saw that the WindowsUpdate.log was showing a 0x80244021 error, which indicates a proxy problem typically. We checked the proxy server and saw that the client was indeed hitting the proxy and getting denied. The odd thing was that, being an internal client, it should have never been hitting the proxy in the first place.
Searching around for known workarounds the simple solution seems to be to add a rule to the Proxy to allow traffic re-direction to the WSUS machine. For my customer, this wasn’t acceptable because (and I agree with them) it is unnecessary load on the proxy and just should not be necessary. I called upon the great experts within Microsoft and found a little known problem related to WPAD files. It turns out that there is a case sensitivity issue. For the proxy they were setting an exception for “wsus.company.domain.com” but in SCCM they had set the FQDN for the WSUS/SUP as “WSUS.COMPANY.DOMAIN.COM” and thus the case mis-match. We first changed the proxy to use the all capital version but found that in the WPAD file which the client receives from the proxy that it was lower case again. We then changed SCCM to be lower case FQDN and saw WUA connect to WSUS correctly and stop hitting the proxy.
My hat is off to Richard Balsley (PFE) and David Chamizo (MCS) for helping identify this very odd behavior.
We are facing the same exact issue. Where did you rename the SCCM site? I only see it listed as all caps in two places. One is the distrubution point (same as the primary site server) and SMS Provider location (which is greyed out.
For my customer we went to site settings/site systems/<server> choose the "ConfigMgr site system" and change the Intranet FQDN to be all lower case.
Hi, that may work for SCCM 2007. But others are now experiencing this issue wit SCCM 2012. Is there any way to change this on 2012, or some other workaround?
Dude - I'm not aware of any way to do this in SCCM 2012. It might come down to modification in the DB tables, which is not supported w/o CSS support to validate that it can be done safely.