Windows Update failing with “Proxy authentication required” 0x8024401B errors

Posted: April 11, 2014 in Configuration Manager, Solved, System Center, Windows Update

This issue isn’t specifically related to Configuration Manager or Windows Updates, but it does seem that Windows Updates itself could behave better to prevent this.

When Windows Updates attempts to connect to the WSUS server (or SUP), you will see the WINDOWSUPDATE.LOG show the client attempting to open the client.asmx file from the WSUS server. The lines following show this connection failing with “SyncUpdates failure, error = 0x8024401B, soap client error = 10, soap error code = 0, HTTP status code = 407” followed by several more 0x8024401b errors.

updates-notworking

These errors are an “HTTP Authentication required” failure. For some reason the client is unable to access the content.

In the instance I was dealing with, the problem isn’t the client connecting to the actual WSUS server. There was an automatic configuration for a proxy.pac file in Internet Explorer and Windows Update was (correctly) also using this to determine how to connect to the server. Unfortunately it was failing all the “DIRECT” rules which it should have matched against and being told to go to the proxy server. So the authentication request is actually coming from the proxy server.

The reason it was failing? The FQDN of the WSUSServer entry was in UPPER CASE and the proxy.pac file was only matching against lower case host names. This may seem crazy, but the proxy.pac matching is indeed case-sensitive.

e.g. A proxy.pac with a rule to match “.domain.com” will not match against a connection to “WSUS.DOMAIN.COM”. It would match “WSUS.domain.com” as it is only the domain part of the FQDN it is checking against.

Most (all?) web browsers will convert whatever URL you type into lower case automatically, so you probably don’t see this issue in normal browsing. It is only when you have “badly behaved” apps like automatic updates that don’t do this, combined with a proxy.pac that also doesn’t handle case insensitivity.

SOLUTION

There are several ways this can be corrected.

Fix the proxy.pac file (Preferred)

  1. Fix the proxy.pac file so that it automatically converts host FQDN strings to lower case before checking them against the rules. This means the host “WSUS.DOMAIN.COM” would be converted to “wsus.domain.com” and then it would check against the rules. This is the best/easiest fix. Here’s a great site explaining everything you could want to know about how to do this: http://webdebug.net/2014/01/proxy-pac-file-tricks-and-tips/
  2. Add an extra matching rule for the upper case condition. e.g. an entry in proxy.pac to match both “.domain.com” AND “.DOMAIN.COM”. While this will work, it is still fallible if someone was to have “.domain.COM” or “DOMAIN.com”. It’s also rather non-obvious to another person who comes along later and wonders why there are “duplicate” rules.

WSUS Only (without ConfigMgr)

  • Check your GPO’s or other reg injection scripts and make sure the WSUS server FQDN is entered in lower case to match the proxy.pac

ConfigMgr 2007

  • You can change the properties of the Site server “Intranet FQDN”. Just make sure to enter it all lower case. That value is the one used to populate the client machines with the name of the SUP server

ConfigMgr 2012

  • You need to specify the name of the server as lower case when you first create the site server in the console. You can’t change it afterwards as there is no “Intranet FQDN” entry as there is in 2007. There are methods involving changing the site server name directly in the database, but this is not officially supported by Microsoft (as with most direct DB editing)
  • If you are running a SUP as a separate server, then remove the role, delete the site server and re-create it with a lower case name. As clients check in and run the scan policy, they will update with the “new” name of the site server in lower case

 

Comments
  1. And If i’m on SCCM 2012 ans SUP is NOT separate server ? what can i do?

    • Scott says:

      I’d suggest looking at option 1 then.
      If this is the problem you are having and there’s no other option, then renaming the “site server” would require uninstalling and reinstalling all the roles on the whole site.
      I can’t recall if doing a site reset would allow you to enter a different name for the site server but I’d have to check that.

    • Scott says:

      Another option though could be to remove the SUP from the existing server and put it on a different server, effectively going you the chance to name the new site server” as needed

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s