Asked by:
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 -
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.dllRan 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 /detectnowAfter 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 /detectnowAfter 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?
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 1, 2014 11:54 PM -
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 2, 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).
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 2, 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 3, 2014 2:37 PM