locked
Windows Server 2012 R2 - WSUS Version: 6.3.9600.16384 - HTTP 407 Proxy authentication required RRS feed

  • Question

  • I have a strange scenario that I can't find answers for and would like some help.  I am running Windows Serever 2012 R2 with WSUS version: 6.3.9600.16384.  I do have an internet proxy in place and have WSUS configured to pass through the proxy server.  Synchronizations work fine but once I have approved a security patch it fails to download those required files.

    When looking at the proxy traces, I can see that WSUS is trying to download from (example):

    http://wsus.ds.download.windowsupdate.com/c/msdownload/update/software/secu/2014/08/windows8.1-kb2988948-x64_6d666d7b2baa07c749f3bbc8322ba9c3a94c0204.cab

    Note: added the <> around http:// because I need to validate my account.  Unfortunately, I am at work and cannot access my email to verify at the moment.

    but the proxy is declining with a HTTP 407 Proxy Authentication Required.  Further investigation shows that the proxy credentials are never sent even though WSUS is configured to use proxy credentials and syncs work.

    Is WSUS not honoring the proxy settings I have configured?  Has anyone found anything to resolve this issue?

    Tuesday, September 30, 2014 7:15 PM

Answers

  • WSUS uses WinHTTP and WinHTTP cannot offer an authenticated connection. But your proxy server requires an authenticated connection.

    To resolve this issue, we have two options,

    1. Exempt the WSUS Server from using the Proxy Server.
    2. Configure the proxy server to allow anonymous connections from the WSUS server.

    Lawrence has explained it clearly in the thread below,

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/bb544234-56e8-452e-80e5-e9a1b26f7d18/wsus-synchronization-error-webexception-the-remore-server-returned-an-error-407-proxy?forum=winserverwsus

    To add some additional clarification to this scenario, which the original thread does a poor job of describing.

    The *WSUS* connection (for synchronization), which is made via WinHTTP, does support proxy authentication. Those proxy credentials are defined in the Update Source and Proxy Server dialog of the WSUS configuration.

    But the *downloads* are not handled by WSUS, they are handled by BITS, and this is where the issue of authentication arises. *BITS* needs to be able to do an anonymous connection via HTTP to do the downloads, because there are no provisions for *BITS* to be able to send proxy authentication.

    With that in mind, it's actually preferable (from the proxy server and proxy users' point of view) to NOT clog up the proxy server with WSUS downloads.. which could measure in the gigabytes per day range, effectively rendering the proxy cache totally useless to the remainder of the clients in the enterprise.

    Ergo, minimum requirement, allow anonymous connections from the WSUS server via HTTP to perform downloads.

    Best option: Allow the WSUS downloads to completely bypass the proxy server, which will eliminate clogging up the proxy cache with gigabytes of content that no other system can ever possibly use.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by crankins76 Monday, October 6, 2014 1:21 PM
    Sunday, October 5, 2014 7:09 AM

All replies

  • Is this forum still monitored?  Cusious if anyone else is having the same issue above?
    Wednesday, October 1, 2014 7:07 PM
  • Hi,

    According to your description, this issue occurs because the proxy server requires an authenticated connection.

    WSUS uses WinHTTP and WinHTTP cannot offer an authenticated connection. But your proxy server requires an authenticated connection.

    To resolve this issue, we have two options,

    1. Exempt the WSUS Server from using the Proxy Server.
    2. Configure the proxy server to allow anonymous connections from the WSUS server.

    Lawrence has explained it clearly in the thread below,

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/bb544234-56e8-452e-80e5-e9a1b26f7d18/wsus-synchronization-error-webexception-the-remore-server-returned-an-error-407-proxy?forum=winserverwsus

    Best Regards.



    Steven Lee

    TechNet Community Support


    Thursday, October 2, 2014 3:05 AM
  • WSUS uses WinHTTP and WinHTTP cannot offer an authenticated connection. But your proxy server requires an authenticated connection.

    To resolve this issue, we have two options,

    1. Exempt the WSUS Server from using the Proxy Server.
    2. Configure the proxy server to allow anonymous connections from the WSUS server.

    Lawrence has explained it clearly in the thread below,

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/bb544234-56e8-452e-80e5-e9a1b26f7d18/wsus-synchronization-error-webexception-the-remore-server-returned-an-error-407-proxy?forum=winserverwsus

    To add some additional clarification to this scenario, which the original thread does a poor job of describing.

    The *WSUS* connection (for synchronization), which is made via WinHTTP, does support proxy authentication. Those proxy credentials are defined in the Update Source and Proxy Server dialog of the WSUS configuration.

    But the *downloads* are not handled by WSUS, they are handled by BITS, and this is where the issue of authentication arises. *BITS* needs to be able to do an anonymous connection via HTTP to do the downloads, because there are no provisions for *BITS* to be able to send proxy authentication.

    With that in mind, it's actually preferable (from the proxy server and proxy users' point of view) to NOT clog up the proxy server with WSUS downloads.. which could measure in the gigabytes per day range, effectively rendering the proxy cache totally useless to the remainder of the clients in the enterprise.

    Ergo, minimum requirement, allow anonymous connections from the WSUS server via HTTP to perform downloads.

    Best option: Allow the WSUS downloads to completely bypass the proxy server, which will eliminate clogging up the proxy cache with gigabytes of content that no other system can ever possibly use.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by crankins76 Monday, October 6, 2014 1:21 PM
    Sunday, October 5, 2014 7:09 AM
  • Thank you for the detailed explanation of the issue I was experiencing.  It helped me a lot.  With this information, we have made the best and most suitable decision concerning our WSUS setup. 
    Monday, October 6, 2014 12:55 PM
  • Hi Lawrence,

    I had a working WSUS 6.3.9600.16384 on windows server 2012 R2 but now I see that the clients This computer has not reported status in x days and is marked red X or yellow !

    Do I need to patch my WSUS or any solution?

    Thanks.

    Wednesday, January 14, 2015 5:03 PM
  • I had a working WSUS 6.3.9600.16384 on windows server 2012 R2 but now I see that the clients This computer has not reported status in x days and is marked red X or yellow !

    Do I need to patch my WSUS or any solution?

    Couldn't possibly say given the information provided.

    I would suggest starting a NEW thread, providing a full description of your environment, and any information on what investigation you've done, or things you've done to try to resolve the issue.

    Most notably it would be useful to know what the client(s) *ARE* doing rather than what they're apparently not doing.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, January 14, 2015 9:02 PM