Installing windows updates into a reference build has long caused hassles for less experienced SCCM admins… in general, as long as you cover the following, it will work:

–          Ensure there is an IP boundary which covers the VLAN the reference machine is on

–          Ensure the SMSMP client property is specified (or if you are still on 2007, the SMSMP and SMSSLP properties)

–          Ensure an updates package is advertised to the record

 

We have recently had a couple of clients with the similar issues, which would usually be explained by one of the above issues, however that was not the case in these instances. In these cases, Windows updates were working fine for everything else apart from the reference build, the correct boundaries and client install properties were there and a package was correctly advertised.

Having a look through the logs:

 

WindowsUpdate.log

WARNING: GetConfig failure, error = 0x80244021, soap client error = 10, soap error code = 0, HTTP status code = 502

WARNING: PTError: 0x80244021

WARNING: GetConfig_WithRecovery failed: 0x80244021

WARNING: RefreshConfig failed: 0x80244021

WARNING: RefreshPTState failed: 0x80244021

WARNING: PTError: 0x80244021

WARNING: Reporter failed to upload events with hr = 80244021.

WARNING: Cached cookie has expired or new PID is available

The important bit of the above error message is HTTP 502, which is a HTTP invalid response.

 

WUAHandlder.log

<![LOG[Scan failed with error = 0x80244021.]LOG]!><time=”08:51:08.954-570″ date=”08-01-2013″ component=”WUAHandler” context=”” type=”3″ thread=”2308″ file=”cwuahandler.cpp:3520″>

 

This log doesn’t actually show us the root cause of the error…. but it is one of the places you look to try and suss out issues with windows updates via SCCM – and the error code is the same as windowsupdate.log

 

Yet another client reported receiving a “Proxy authentication” error – I do not have the logs from that client, but the fix was the same.

These clients used WPAD to allocate proxy settings – and WPAD is case sensitive as per http://blogs.technet.com/b/isablog/archive/2010/11/11/case-sensitivity-of-isa-tmg-generated-proxy-auto-configuration-pac-files.aspx

 

Each of the clients having the issue, had a wildcard exclusion for the active software update point, however, we were not convinced it was working – and rather than test, it was quicker to simply add the URL into the proxy exclusion list, in the case it was in – and see if it worked…. and it did.

Now that we knew what the error was – it was a bit easier to google and find other examples of people confirming the “issue” such as:

http://blogs.technet.com/b/michaelgriswold/archive/2011/07/08/wua-can-t-contact-wsus.aspx

 

We seem to be seeing this error in SCCM 2012 a bit more, as SCCM 2012 by default uses the FQDN of the active software update point in all caps… e.g. SCCM2012.COMPANY.COM. This could be modified in SCCM 2007, but not in 2012. (Well, technically you could modify it in the database, but that would be unsupported)

 

So, in short, if you’re having trouble with your software updates being delivered and are using WPAD

–          open the windowsupdate.log

–          copy and paste the URL into your WPAD file as an exclusion (so you get the exact case that is being used by the windows update client)