none
Domain Group Policy changes causes clients to be unable to connect to WSUS for Windows Updates

    Question

  • Domain Controller is Windows Server 2008 R2 64-bit, Group Policy Management version 6.0.0.1. WSUS server is Windows Server 2008 Enterprise 32-bit, Update Services version 3.2.7600.226. Client machines are Windows 7, some are 64-bit and some are 32-bit.

    Every time we make any changes to any of our Group Policies most of our clients stop getting their Windows Updates from the WSUS server within 2-3 days. This occurs when we add a new policy for a group of users, temporarily disable a policy or edit a policy. Check of the WindowsUpdate.log on affected client machines shows:

    2014-06-25 13:40:44:976  760 1610 PT WARNING: GetAuthorizationCookie failure, error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status code = 200
    2014-06-25 13:40:44:977  760 1610 PT WARNING: Failed to initialize Simple Targeting Cookie: 0x80072ee2
    2014-06-25 13:40:44:977  760 1610 PT WARNING: PopulateAuthCookies failed: 0x80072ee2
    2014-06-25 13:40:44:977  760 1610 PT WARNING: RefreshCookie failed: 0x80072ee2
    2014-06-25 13:40:44:977  760 1610 PT WARNING: RefreshPTState failed: 0x80072ee2
    2014-06-25 13:40:44:977  760 1610 PT WARNING: PTError: 0x80072ee2
    2014-06-25 13:40:44:977  760 1610 Report WARNING: Reporter failed to upload events with hr = 80072ee2.

    A further check of the log files shows:

    2014-06-21 19:36:06:995  156 1b0c Misc WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <proxy server name:8080> Bypass List used : <(null)> Auth Schemes used : <>

    We do not use a proxy except for Internet connections. We configure IE with a pac file. This is set through Group Policy since we restrict user accounts from being able to set it. 

    The clients that are connecting to the WSUS server have these entries instead:

    2014-06-24 09:12:16:779  992 270 Agent Setting download properties on call A20329BC-3467-4B7E-B9F4-6AC6ACBA23E1: priority=3, interactive=1, owner is system=0, proxy settings=1, proxy session id=2

    I have a routine that will fix the problem but it is time-consuming and pulls me away from other things I should be doing:

    Run registry files on client machine (WindowsUpdate and AU) This is not always necessary and is already set by Group Policy and the affected clients already have the registry settings. No idea why it is necessary to do but it the steps below don't always work unless it is.

    netstop bits and netstop wuauserv

    ipconfig /flushdns

    Delete qmgr*.* files from Downloader folder

    Delete Software Distribution folder

    Run from command prompt:

    sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

    sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

    netstart bits and netstart wuauserv

    wuauclt /resetauthorization /detectnow

    Run Windows Updates again from Control Panel

    This routine always fixes the problem but I've found that I must do each step to guarantee success.

    How or where is the proxy setting being changed for WSUS that we see in the WindowsUpdate logs and how do I prevent this from happening? It is also curious that it happens to most but not all of the client machines. When it does happen it's not always the same client machines.

    Wednesday, June 25, 2014 6:45 PM

All replies

  • The Windows Update Agent does not use the same proxy configuration as the browser.

    If you're configuring IE with a PAC that means you're NOT configuring WinHTTP at all.

    2014-06-21 19:36:06:995  156 1b0c Misc WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <proxy server name:8080>

    And yet, it seems the WUA does have a proxy configuration and it doesn't like it. The 0x80072EE2 is a TIMEOUT ERROR... likely because the connection is failing through the proxy server.

    Presumably the WSUS server is NOT on the other side of a proxy server and does not require a proxy server, so you should CLEAR the proxy configuration for WinHTTP using netsh winhttp reset proxy.


    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, June 25, 2014 9:09 PM
    Moderator
  • You're right - the WSUS server is on the inside and does not need a proxy server. Tried running the netsh winhttp reset proxy command but was still not able to connect to the WSUS server. After running the netsh winhttp reset proxy command received response: Current WinHTTP proxy setting: Direct access <no proxy server>.

    Ran the command at 13:49 and then tried Windows Updates again. Here's snippet from the log file:

    2014-06-27 13:49:56:889  548 f6c AU Triggering AU detection through DetectNow API
    2014-06-27 13:49:56:890  548 f6c AU Triggering Online detection (interactive)
    2014-06-27 13:49:56:890  548 4b8 AU #############
    2014-06-27 13:49:56:890  548 4b8 AU ## START ##  AU: Search for updates
    2014-06-27 13:49:56:890  548 4b8 AU #########
    2014-06-27 13:49:56:893  548 4b8 AU <<## SUBMITTED ## AU: Search for updates [CallId = {9CE06AB2-E859-4B4D-8D1A-193AD89623C5}]
    2014-06-27 13:49:56:893  548 1260 Agent *************
    2014-06-27 13:49:56:893  548 1260 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2014-06-27 13:49:56:893  548 1260 Agent *********
    2014-06-27 13:49:56:893  548 1260 Agent   * Online = Yes; Ignore download priority = No
    2014-06-27 13:49:56:893  548 1260 Agent   * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
    2014-06-27 13:49:56:893  548 1260 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2014-06-27 13:49:56:893  548 1260 Agent   * Search Scope = {Machine}
    2014-06-27 13:49:56:893  548 1260 Setup Checking for agent SelfUpdate
    2014-06-27 13:49:56:893  548 1260 Setup Client version: Core: 7.6.7600.256  Aux: 7.6.7600.256
    2014-06-27 13:49:56:894  548 1260 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2014-06-27 13:49:56:901  548 1260 Misc  Microsoft signed: Yes
    2014-06-27 13:49:56:927  548 1260 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2014-06-27 13:49:56:934  548 1260 Misc  Microsoft signed: Yes
    2014-06-27 13:49:56:936  548 1260 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
    2014-06-27 13:49:56:943  548 1260 Misc  Microsoft signed: Yes
    2014-06-27 13:49:56:956  548 1260 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
    2014-06-27 13:49:56:962  548 1260 Misc  Microsoft signed: Yes
    2014-06-27 13:49:56:974  548 1260 Setup Determining whether a new setup handler needs to be downloaded
    2014-06-27 13:49:56:974  548 1260 Setup SelfUpdate handler is not found.  It will be downloaded
    2014-06-27 13:49:56:974  548 1260 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.6.7600.256"
    2014-06-27 13:49:56:976  548 1260 Setup Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.6.7600.256" is already installed.
    2014-06-27 13:49:56:976  548 1260 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.256"
    2014-06-27 13:49:56:989  548 1260 Setup Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.256" is already installed.
    2014-06-27 13:49:56:989  548 1260 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.256"
    2014-06-27 13:49:57:007  548 1260 Setup Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.256" is already installed.
    2014-06-27 13:49:57:007  548 1260 Setup SelfUpdate check completed.  SelfUpdate is NOT required.
    2014-06-27 13:49:57:165  548 1260 PT +++++++++++  PT: Synchronizing server updates  +++++++++++
    2014-06-27 13:49:57:165  548 1260 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://(FQDN of WSUS server)/ClientWebService/client.asmx
    2014-06-27 13:49:57:175  548 1260 PT WARNING: Cached cookie has expired or new PID is available
    2014-06-27 13:49:57:175  548 1260 PT Initializing simple targeting cookie, clientId = 6be4a1ae-3313-4855-bdb1-57e3312f03ec, target group = AGENCIES, DNS name = dpk2.clear-rcic.rcc.org
    2014-06-27 13:49:57:175  548 1260 PT   Server URL = http://(FQDN of WSUS server)/SimpleAuthWebService/SimpleAuth.asmx
    2014-06-27 13:50:57:280  548 1260 Misc WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(proxy server):8080> Bypass List used : <(null)> Auth Schemes used : <>
    2014-06-27 13:50:57:281  548 1260 PT   + Last proxy send request failed with hr = 0x80072EE2, HTTP status code = 0
    2014-06-27 13:50:57:281  548 1260 PT   + Caller provided proxy = No
    2014-06-27 13:50:57:281  548 1260 PT   + Proxy list used = webgate.rcc.org:8080
    2014-06-27 13:50:57:281  548 1260 PT   + Bypass list used = <NULL>
    2014-06-27 13:50:57:281  548 1260 PT   + Caller provided credentials = No
    2014-06-27 13:50:57:281  548 1260 PT   + Impersonate flags = 0
    2014-06-27 13:50:57:281  548 1260 PT   + Possible authorization schemes used =
    2014-06-27 13:50:57:281  548 1260 PT WARNING: GetAuthorizationCookie failure, error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status code = 200
    2014-06-27 13:50:57:281  548 1260 PT WARNING: Failed to initialize Simple Targeting Cookie: 0x80072ee2
    2014-06-27 13:50:57:281  548 1260 PT WARNING: PopulateAuthCookies failed: 0x80072ee2
    2014-06-27 13:50:57:281  548 1260 PT WARNING: RefreshCookie failed: 0x80072ee2
    2014-06-27 13:50:57:281  548 1260 PT WARNING: RefreshPTState failed: 0x80072ee2
    2014-06-27 13:50:57:281  548 1260 PT WARNING: Sync of Updates: 0x80072ee2
    2014-06-27 13:50:57:281  548 1260 PT WARNING: SyncServerUpdatesInternal failed: 0x80072ee2
    2014-06-27 13:50:57:281  548 1260 Agent   * WARNING: Failed to synchronize, error = 0x80072EE2
    2014-06-27 13:50:57:282  548 1260 Agent   * WARNING: Exit code = 0x80072EE2
    2014-06-27 13:50:57:282  548 1260 Agent *********
    2014-06-27 13:50:57:282  548 1260 Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2014-06-27 13:50:57:282  548 1260 Agent *************
    2014-06-27 13:50:57:282  548 1260 Agent WARNING: WU client failed Searching for update with error 0x80072ee2
    2014-06-27 13:50:57:302  548 e04 AU >>##  RESUMED  ## AU: Search for updates [CallId = {9CE06AB2-E859-4B4D-8D1A-193AD89623C5}]
    2014-06-27 13:50:57:302  548 e04 AU   # WARNING: Search callback failed, result = 0x80072EE2
    2014-06-27 13:50:57:302  548 e04 AU   # WARNING: Failed to find updates with error code 80072EE2
    2014-06-27 13:50:57:302  548 e04 AU #########
    2014-06-27 13:50:57:302  548 e04 AU ##  END  ##  AU: Search for updates [CallId = {9CE06AB2-E859-4B4D-8D1A-193AD89623C5}]
    2014-06-27 13:50:57:302  548 e04 AU #############
    2014-06-27 13:50:57:303  548 e04 AU Successfully wrote event for AU health state:0
    2014-06-27 13:50:57:303  548 e04 AU AU setting next detection timeout to 2014-06-27 22:50:57
    2014-06-27 13:50:57:304  548 e04 AU Setting AU scheduled install time to 2014-06-28 05:00:00
    2014-06-27 13:50:57:304  548 e04 AU Successfully wrote event for AU health state:0
    2014-06-27 13:50:57:305  548 e04 AU Successfully wrote event for AU health state:0
    2014-06-27 13:51:02:285  548 1260 Report REPORT EVENT: {BD25B39C-6570-454C-A046-AF3AF2DEBDD4} 2014-06-27 13:50:57:282-0400 1 148 101 {00000000-0000-0000-0000-000000000000} 0 80072ee2 AutomaticUpdates Failure Software Synchronization Windows Update Client failed to detect with error 0x80072ee2.
    2014-06-27 13:51:02:295  548 1260 Report CWERReporter::HandleEvents - WER report upload completed with status 0x8
    2014-06-27 13:51:02:295  548 1260 Report WER Report sent: 7.6.7600.256 0x80072ee2 00000000-0000-0000-0000-000000000000 Scan 101 Managed
    2014-06-27 13:51:02:295  548 1260 Report CWERReporter finishing event handling. (00000000)
    2014-06-27 13:51:48:184  548 4b8 AU ###########  AU: Uninitializing Automatic Updates  ###########
    2014-06-27 13:51:48:187  548 4b8 DnldMgr FATAL: DM:CBitsJob::SetCallbackHandler: SetNotifyInterface failed with 0x80080008.
    2014-06-27 13:51:48:187  548 4b8 DnldMgr FATAL: DM:CBitsJob::SetCallbackHandler: SetNotifyInterface failed with 0x80080008.
    2014-06-27 13:51:48:187  548 4b8 DnldMgr FATAL: DM:CBitsJob::SetCallbackHandler: SetNotifyInterface failed with 0x80080008.
    2014-06-27 13:51:48:187  548 4b8 DnldMgr FATAL: DM:CBitsJob::SetCallbackHandler: SetNotifyInterface failed with 0x80080008.
    2014-06-27 13:51:48:187  548 4b8 Report CWERReporter finishing event handling. (00000000)
    2014-06-27 13:51:48:252  548 4b8 Service *********
    2014-06-27 13:51:48:252  548 4b8 Service **  END  **  Service: Service exit [Exit code = 0x240001]
    2014-06-27 13:51:48:252  548 4b8 Service *************
    2014-06-27 13:51:53:002  548 160c Misc ===========  Logging initialized (build: 7.6.7600.256, tz: -0400)  ===========
    2014-06-27 13:51:53:002  548 160c Misc   = Process: C:\Windows\system32\svchost.exe
    2014-06-27 13:51:53:002  548 160c Misc   = Module: c:\windows\system32\wuaueng.dll

    Ran a batch file which resets the AU and WindowsUpdate registry keys and then runs the steps listed above:

    regedit /s C:\WindowsUpdate.reg
    regedit /s C:\AU.reg
    net stop bits
    net stop wuauserv
    Ipconfig /flushdns
    del C:\ProgramData\Microsoft\Network\Downloader\qmgr*.*
    del  /F /Q C:\Windows\SoftwareDistribution\*.*
    sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
    sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
    net start bits
    net start wuauserv
    wuauclt /resetauthorization /detectnow

    After this runs, am able to connect to WSUS server for updates. I mentioned Group Policy changes because this only breaks after the Group Policy changes. It doesn't affect every client machine but most of them. Was wondering how the proxy gets reset from none to the proxy server for Windows Updates?

    Friday, June 27, 2014 6:40 PM
  • 2014-06-27 13:49:57:165  548 1260 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://(FQDN of WSUS server)/ClientWebService/client.asmx
    2014-06-27 13:49:57:175  548 1260 PT WARNING: Cached cookie has expired or new PID is available
    2014-06-27 13:49:57:175  548 1260 PT Initializing simple targeting cookie, clientId = 6be4a1ae-3313-4855-bdb1-57e3312f03ec, target group = AGENCIES, DNS name = dpk2.clear-rcic.rcc.org
    2014-06-27 13:49:57:175  548 1260 PT   Server URL = http://(FQDN of WSUS server)/SimpleAuthWebService/SimpleAuth.asmx
    2014-06-27 13:50:57:280  548 1260 Misc WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(proxy server):8080> Bypass List used : <(null)> Auth Schemes used : <>
    2014-06-27 13:50:57:281  548 1260 PT   + Last proxy send request failed with hr = 0x80072EE2, HTTP status code = 0
    2014-06-27 13:50:57:281  548 1260 PT   + Caller provided proxy = No
    2014-06-27 13:50:57:281  548 1260 PT   + Proxy list used = webgate.rcc.org:8080
    2014-06-27 13:50:57:281  548 1260 PT   + Bypass list used = <NULL>

    Ran a batch file which resets the AU and WindowsUpdate registry keys and then runs the steps listed above:

    regedit /s C:\WindowsUpdate.reg
    regedit /s C:\AU.reg
    net stop bits
    net stop wuauserv
    Ipconfig /flushdns
    del C:\ProgramData\Microsoft\Network\Downloader\qmgr*.*
    del  /F /Q C:\Windows\SoftwareDistribution\*.*
    sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
    sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
    net start bits
    net start wuauserv
    wuauclt /resetauthorization /detectnow

    After this runs, am able to connect to WSUS server for updates. I mentioned Group Policy changes because this only breaks after the Group Policy changes. It doesn't affect every client machine but most of them. Was wondering how the proxy gets reset from none to the proxy server for Windows Updates?

    "something" is setting a machine-level proxy.
    Given that you have the issue (a machine-level proxy becomes configured) after you perform GPO changes, and, given that GPO is typically (by default) applied once and only re-applied when the GPO is subject to change/edit - it sure sounds like you have a Domain-GP-related setting as your cause.
    You could confirm this, by getting a machine which is "correctly" working, and then perform "gpupdate /force" on it. If the proxy problem occurs on this machine, start checking into Domain GP, or other Local GP, to see where the setting is coming from.
    Some products/solutions (including some MS products) will create settings via Local GP methods (or directly via registry settings), so, even if your Domain GP is clear of such settings, it could be another "security" product or something like that.

    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!)


    • Edited by DonPick Saturday, June 28, 2014 10:45 AM
    Saturday, June 28, 2014 10:44 AM
  • > ...GPO is typically (by default) applied once and only re-applied when the GPO is subject to change/edit

    Yes, that's true if you not consider GPP as GPO. GPPs can be configured to be applied at every refresh by not checking "Apply once and do not reapply".

    Proxy settings for the Local System account is found here:

    HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
    "DefaultConnectionSettings" REG_BINARY



    Rolf Lidvall, Swedish Radio (Ltd)

    Monday, June 30, 2014 12:47 PM
  • > ...GPO is typically (by default) applied once and only re-applied when the GPO is subject to change/edit

    Yes, that's true

    Actually it's not true.

    Domain Member computers refresh all Group Policy Objects every 90 minutes +/- 30 minutes.

    This can be evidenced by changing any one of those registry values that's configured by policy. Wait two hours. I promise you it will magically change back to the original value (the one defined by the GPO).

    *GPP*s, as noted, can be configured to apply only once using the identified option.


    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.

    Tuesday, July 01, 2014 11:54 PM
    Moderator
  • Of course you're right, I have no idea what I was thinking about. First day at work after vacation to add to the confusion...

    Rolf Lidvall, Swedish Radio (Ltd)

    Wednesday, July 02, 2014 6:44 AM
  • Domain Member computers refresh all Group Policy Objects every 90 minutes +/- 30 minutes.

    This can be evidenced by changing any one of those registry values that's configured by policy. Wait two hours. I promise you it will magically change back to the original value (the one defined by the GPO).

    That's only true if the default behaviour hasn't been suppressed, and suppression is a configurable option.
    We have, in the past, suppressed that behaviour, in certain circumstances.
    (but I freely admit that it's a rather rare, special case. in my experience ;)

    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, July 02, 2014 8:27 AM
  • I checked all Group Policy's and the registry on a few of the machines affected. Checked for the proxy name but did not find it anywhere. Both the policies and the registry setting refer to the pac file. The pac file essentially says if host is internal (it is) return "DIRECT" otherwise use the proxy. The pac file is the only thing I can find that directly names the proxy. Could this be occurring because the WSUS server gets too many requests to handle at once when the policy is updated? When I looked at the Windows System logs and Windows Update logs for a few of the client machines affected. The error appeared just shortly after Group Policy was applied. The errors appeared in the Windows Update log just a few minutes apart for the clients.
    Thursday, July 03, 2014 2:37 PM