locked
Software Update Agent using proxy with WPAD RRS feed

  • Question

  • Hi,

     

    Does anyone know how I can set the Software Update Agent to bypass the proxy server when using ISA WPAD?

     

    I have a problem where all of my clients' scan states are showing as "unknown", and all get the following errors in the logs:

     

    <![LOG[Async searching of updates using WUAgent started.]LOG]!><time="15:44:05.341+000" date="10-06-2008" component="WUAHandler" context="" type="1" thread="1036" file="cwuahandler.cpp:587">
    <![LOG[Async searching completed.]LOG]!><time="15:44:07.466+000" date="10-06-2008" component="WUAHandler" context="" type="1" thread="5696" file="cwuahandler.cpp:2099">
    <![LOG[OnSearchComplete - Failed to end search job. Error = 0x80244021.]LOG]!><time="15:44:07.466+000" date="10-06-2008" component="WUAHandler" context="" type="3" thread="1036" file="cwuahandler.cpp:2966">
    <![LOG[Scan failed with error = 0x80244021.]LOG]!><time="15:44:07.466+000" date="10-06-2008" component="WUAHandler" context="" type="3" thread="1036" file="cwuahandler.cpp:3223">

     

    I have discovered this means that the agent is trying to use the proxy server to communicate with SCCM, ie to get to http://svsccm02.dbct.com.au/ClientWebService/client.asmx. We are using wpad with ISA 2006 so no doubt this is where it is pulling the proxy address from. By default, this address is blocked using the proxy; when I add it in the scan is successful.

     

    The thing is, our wpad script is set to go directly to all internal servers (bypass the proxy), and if I browse to that address on the clients it does indeed bypass the ISA server. I have tried a bunch of windows update agent commands (proxycfg -b, wuauclt.exe /forcedetect etc.) but I'm starting to come to the conclusion that the agent pays no attention to the Windows Update Agent settings. Detailed documentation on how the SCCM agent integrates with WU seems very scarce in general.

     

    I don't really want to have to enable access via the proxy server. Any help with this would be much appreciated.

     

    Regards,

    Shaw

    Monday, October 6, 2008 8:56 AM

Answers

  • Thanks Don. Finding this issue frustrating now. It only appeared on new SCCM2012 client after SCCM2012 SP1 was installed. Would you mind explaining about the wpad changes you made? Unfortunately I was unware of wpad until this week when I started researching this issue. Thanks again. 

    We have added an upper cased rule to our proxy.pac (which our workstations locate via the wpad method).

    Our proxy.pac (or wpad.dat) has for many years contained logic like this:

        if (dnsDomainIs(host, ".in.contoso.com"))

            return DIRECT;

    So we had to add this:

        if (dnsDomainIs(host, ".IN.CONTOSO.COM"))

            return DIRECT;


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, June 13, 2013 8:59 PM
  • After a few days of banging my head against the wall, I have found a solution that is working for me.  WSUS/SCCM uses the computer's WinHTTP settings, found by using the proxycfg command line tool.  I used this command to point client computers to my proxy server:  proxycfg -p wpad:8080  It seemed that re-running the Software Update Scan would continue to fail until the client computer was rebooted.  So, to be safe I rebooted after making a change with proxycfg.  I made the exception for the WSUS/SCCM server on the proxy server itself and not on each client with proxycfg.

    The part that I found frustrating is that simply changing the WinHTTP settings to direct or removing the HKLM proxy key entirely does not allow WSUS/SCCM to access the server directly.  It would appear that if your environment uses WPAD, you have to point WinHTTP to your proxy server.  How is this not broken?

    To give all client computers this setting, I added this to our startup script:
    WshShell.Run "proxycfg -p wpad:8080", 0, True

    I also wanted to make sure that all ie browsers were pointed to our proxy server and put this into our logon script:  This chunk sets each user's browser settings to Automatically Detect Proxy Settings.  The section of group policy that handles this(IE Maintenance) has never worked reliably for me so now I'm doing it with scripting.
    'Set Auto detect settings on
    DIM sKey,sValue,binaryVal
    Dim oReg
    Set oReg=GetObject( "winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")    'For registry operations througout
    Const HKCU=&H80000001
    sKey = "Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections"
    sValue = "DefaultConnectionSettings"
    oReg.GetBinaryValue HKCU, sKey, sValue, binaryVal
    binaryVal(8) = binaryVal(8) OR 8        'Force Autodetect on
    oReg.SetBinaryValue HKCU, sKey, sValue, binaryVal
    • Proposed as answer by Sean_Aus Monday, August 24, 2009 2:58 AM
    • Marked as answer by Garth JonesMVP Saturday, January 2, 2016 4:57 PM
    Wednesday, August 12, 2009 5:49 PM

All replies

  • Hello!

    Were You able to resolve this issue?

    Any comments from Microsoft?


    Thanks,
    Peteris
    Friday, August 7, 2009 9:28 AM
  • Having the same problem here.
    Friday, August 7, 2009 7:52 PM
  • Hi!

    Is there any chance to get an answer to this question here or we should create a support case?


    This is a very important question, because patches ar coming this week and we do not want to leave our computers unpatched!

    Thanks,
    Peteris
    Monday, August 10, 2009 7:01 AM
  • After a few days of banging my head against the wall, I have found a solution that is working for me.  WSUS/SCCM uses the computer's WinHTTP settings, found by using the proxycfg command line tool.  I used this command to point client computers to my proxy server:  proxycfg -p wpad:8080  It seemed that re-running the Software Update Scan would continue to fail until the client computer was rebooted.  So, to be safe I rebooted after making a change with proxycfg.  I made the exception for the WSUS/SCCM server on the proxy server itself and not on each client with proxycfg.

    The part that I found frustrating is that simply changing the WinHTTP settings to direct or removing the HKLM proxy key entirely does not allow WSUS/SCCM to access the server directly.  It would appear that if your environment uses WPAD, you have to point WinHTTP to your proxy server.  How is this not broken?

    To give all client computers this setting, I added this to our startup script:
    WshShell.Run "proxycfg -p wpad:8080", 0, True

    I also wanted to make sure that all ie browsers were pointed to our proxy server and put this into our logon script:  This chunk sets each user's browser settings to Automatically Detect Proxy Settings.  The section of group policy that handles this(IE Maintenance) has never worked reliably for me so now I'm doing it with scripting.
    'Set Auto detect settings on
    DIM sKey,sValue,binaryVal
    Dim oReg
    Set oReg=GetObject( "winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")    'For registry operations througout
    Const HKCU=&H80000001
    sKey = "Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections"
    sValue = "DefaultConnectionSettings"
    oReg.GetBinaryValue HKCU, sKey, sValue, binaryVal
    binaryVal(8) = binaryVal(8) OR 8        'Force Autodetect on
    oReg.SetBinaryValue HKCU, sKey, sValue, binaryVal
    • Proposed as answer by Sean_Aus Monday, August 24, 2009 2:58 AM
    • Marked as answer by Garth JonesMVP Saturday, January 2, 2016 4:57 PM
    Wednesday, August 12, 2009 5:49 PM
  • I have run into the same problem. Our clients that connect via a VPN client to the network are not able to scan for updates.

    Upon checking the C:\WINDOWS\WindowsUpdate.log file I noticed the following line:
     
    WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <IP address of the ISA server:8080> Bypass List used : <(null)> Auth Schemes used : <>

    This seems to me that a client is trying to connect to the SCCM server (to scan for new updates) via the ISA server and it fails.

    We don't have winhttp configured on the client and I assume that the proxy details are retrieved via the wpad entry in DNS.

    On a windows 7 test client I have created a bypass list using the netsh command. (netsh winhttp set proxy wpad:8080 bypass-list="*.domain.local").

    I established a VPN connection and started a update scan cycle while having the C:\WINDOWS\WindowsUpdate.log file open. All seems to work fine now. So to sum this up, If I use a bypass list to exclude the local domain suffix it works like a charm.

    (Please note that we do have the option in internet explorer enabled to automatically detect settings but even if I uncheck this option it still uses the proxy server to connect to the SCCM server.)

    So in order to use the (sccm) update facility for clients that connect to the network via VPN I need to add a proxy and bypass list using either netsh winhttp or proxycfg command? I would rather add some kind of exception to the ISA firewall, but which exception....?

    (Also one thing I tried is to delete the wpad entry in DNS and then everything works fine as well!). 

    Perhaps anyone can commend on these findings?

    Thanks.




    Wednesday, November 18, 2009 10:23 AM
  • This is interesting:
    http://social.technet.microsoft.com/Forums/en/configmgrsum/thread/0abd07d9-875a-4f0f-8d34-346fa66d2ca7

    I haven't tried it yet but someone has discovered that using Uppercase letters in the FQDN forces Software Update to use a proxy server.  I will be changing mine to lowercase to see if it works.
    Monday, January 11, 2010 7:24 PM
  • The solution that was working for me above stopped working in November for some unknown reason.  To fix it I had to revert the proxycfg command that I had in the desktop startup script, like this:  WshShell.Run "proxycfg -d", 0, True
    I also changed the Site System's Intranet FQDN to all lowercase although I don't know if this had any effect.  Regardless, desktops are able to get Windows Updates again without seeing any weird proxy errors.

    Tuesday, January 12, 2010 9:07 PM
  • Did you change the FQDN to lower case in the 2007 SCCM console? Looks like this issue also exists I'm 2012, but apparently can't change it there. Looking at making some database modifications instead
    Wednesday, June 12, 2013 7:23 PM
  • Did you change the FQDN to lower case in the 2007 SCCM console? Looks like this issue also exists I'm 2012, but apparently can't change it there. Looking at making some database modifications instead

    we've also seen this issue with ConfigMgr2012SP1CU1 + Win8, with our wpad and proxy.pac combination.

    we opened a premier case, and were advised that this is a known issue, and no current plans to address it.

    we peeked in the db here and there but couldn't get it working, suspect some hard-coding somewhere...

    we edited our proxy.pac to workaround this defect, but not happy about it.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, June 12, 2013 9:45 PM
  • Thanks Don. Finding this issue frustrating now. It only appeared on new SCCM2012 client after SCCM2012 SP1 was installed. Would you mind explaining about the wpad changes you made? Unfortunately I was unware of wpad until this week when I started researching this issue. Thanks again. 
    Thursday, June 13, 2013 9:45 AM
  • Thanks Don. Finding this issue frustrating now. It only appeared on new SCCM2012 client after SCCM2012 SP1 was installed. Would you mind explaining about the wpad changes you made? Unfortunately I was unware of wpad until this week when I started researching this issue. Thanks again. 

    We have added an upper cased rule to our proxy.pac (which our workstations locate via the wpad method).

    Our proxy.pac (or wpad.dat) has for many years contained logic like this:

        if (dnsDomainIs(host, ".in.contoso.com"))

            return DIRECT;

    So we had to add this:

        if (dnsDomainIs(host, ".IN.CONTOSO.COM"))

            return DIRECT;


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, June 13, 2013 8:59 PM