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.