KB2919355 (8.1. update 1) breaks WSUS clients

All replies

• 

  

  0

  Sign in to vote

  How about we get an official support case opened so that we can get this in front of Microsoft.

  Email me at susan-at-msmvps.com (change the -at- to @) and I'll set up a free support case for you.

  ---

  Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

  Monday, April 7, 2014 2:06 AM
• 

  

  0

  Sign in to vote

  Can confirm the issue.

  Running WSUS on Server 2008R2.

  Maybe there is an update for WSUS coming tomorrow?

  Monday, April 7, 2014 1:55 PM
• 

  

  0

  Sign in to vote

  May I open an official support case for you guys so we can get this tracked?

  Email me at susan-at-msmvps.com (change the -at- to @)

  ---

  Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

  Monday, April 7, 2014 4:21 PM
• 

  

  0

  Sign in to vote

  Hang on, you are confirming  that 2919355 applied to the clients will break communication with a WSUS installed on 2008r2, yes?

  Not his situation where 2919355 applied to the server breaks communication to the clients, yes?

  ---

  Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

  Monday, April 7, 2014 4:28 PM
• 

  

  0

  Sign in to vote

  For us to better assist you, can you please specify:

  1. Which version of WSUS do you have installed and on which version of Windows Server?
  2. Please list any QFE (KB#s) that you have installed on the WSUS server.

  Thanks,
  Ben

  Monday, April 7, 2014 4:30 PM
• 

  

  0

  Sign in to vote

  In particular, I'd like to check what you have installed for the Windows 8.1 spring '14 update on the WS2012 client computer that has the problem. There are 5 OS update packages that form this update, and I'm concerned that you may not have installed them all, in which case the client is not in a supported state.
  

  • Edited by Michael Ratanapintha - MSFTMicrosoft employee Monday, April 7, 2014 5:16 PM

  Monday, April 7, 2014 4:37 PM
• 

  

  0

  Sign in to vote

  KB2949621-v2 doesn't want to install on servers that I've found.

  ---

  Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

  Monday, April 7, 2014 4:40 PM
• 

  

  0

  Sign in to vote

  KB2949621-v2 doesn't want to install on servers that I've found.

  ---

  Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

  
  That's OK and expected. The KB2949621-v2 part of the spring '14 update only applies if you have BitLocker support installed; BitLocker support isn't installed by default on server editions (though it can be installed through the Add Roles and Features wizard).
  

  Monday, April 7, 2014 5:14 PM
• 

  

  0

  Sign in to vote

  The server OS is Server 2008R2, the WSUS server version reports as 3.2.7600.256 in the management snapin. It is up to date as far as i'm aware. I'm using ssl with self-signed certificates which is working on vista, 7 8 and various server flavours of those. The server continues to work for all other clients.

  On the 2012R2 client systems I have 2 systems which have all the updates installed. One took the KB2949621-v2 update and the other didn't. In both cases I installed the updates in the order listed in the readme.txt file provided. Neither of those systems can get updates from the WSUS server anymore. At least one of those systems is in a supported state. I suspect both are but I leave that to you to decide.

  When I found the issue I built a clean vm from scratch with no third party software and minimal configuration. I stopped testing once I had verified that KB2919355 was the first patch which caused the issue and that uninstalling only that patch restored the desired behaviour. Given that the desired behaviour does not return if the further patches are installed it seems a reasonable place to start looking to diagnose the problem more completely.

  St3fan_ has confirmed that he can replicate the issue so if all my systems are in an unsupported state it may be that his are not. He may have information to add.

  I've been using WSUS since it was version 1 and called SUS. I've had some experience configuring and troubleshooting it over the years. This doesn't seem to be an issue caused by incorrect client configuration to me. If i'm wrong i'd still like to know how to fix it so I can update my development machines.

  Monday, April 7, 2014 5:21 PM
• 

  

  0

  Sign in to vote

  In my situation the WSUS server is on 2008R2, the clients are 2012R2+update1. Sorry if this wasn't clear.

  I'm aware that there are compatibility issues with 2012R2 clients in relation to third party published updates but the core functionality has been working successfully until now.

  Monday, April 7, 2014 5:24 PM
• 

  

  0

  Sign in to vote

  Hi David,

  We apologize for the inconvenience. If you still have the machine with KB2919355 installed, would you please do the following?

  1. Open 'Event Viewer'
  2. Browse to 'Application and Services Logs' > Microsoft > Windows > CAPI2 > Operational.
  3. Right click on 'Operational' in the directory tree, and select 'Enable log'
  4. Have your WU client scan against your WSUS again to reproduce the failure.
  5. Go back to Event Viewer and export the CAPI2 events by clicking 'Save All Events As ..."
  6. Please share the CAPI2 log with us.
  
  Note that this may expose some details about your SSL cert to us. If you're not comfortable doing that, please kindly let us know the details of your SSL cert:
  

  1. Signature algorithm: MD5, SHA1, SHA2?
  2. Public key length: 1024 or 2048 bits?
  
  They can be found from the cert properties when you double click it. Thank you very much.

  Regards,
  Leo Lie [MSFT]
  SDET, Windows Update Client

  Monday, April 7, 2014 6:08 PM
• 

  

  0

  Sign in to vote

  The certificate is self signed and never used outside my home network. The details can't be used to damage anything so I have no problem sharing information about it. I can provide it if it helps.

  The zipped log file from the vm with all patches installed (and is in a supported state) is uploaded here https://app.box.com/s/7l4llh9xb0tzpdpy14ip

  Monday, April 7, 2014 6:33 PM
• 

  

  0

  Sign in to vote

  My Server is 2008R2 SP1 fully patched. WSUS Console shows 3.2.7600.256.

  It also uses SSL, but with a public cert. It patches 2500 Clients in our environment without a problem
  

  When I setup a clean VM with Windows 8.1 it can communicate with the WSUS and download updates.

  But when I install the Update 1 for 8.1, it cannot communicate anymore and I get the error.

  If I remember correctly when Win8 came out there was kind of the same issue. Had to install an update on the WSUS to get it working with Win8.

  Monday, April 7, 2014 6:46 PM
• 

  

  0

  Sign in to vote

  Thanks for trying that out, David.

  I can't find the part where WU tried to verify the SSL cert of https://server2 in the CAPI2 logging. Do you mind trying clearing the log, and check for updates again?

  In addition to the CAPI2 events, please also share:

  1. Updated WindowsUpdate.log
  2. The certificate chain too if you don't mind, so I can import it to my WSUS and try to repro this in-house.
  
  Thanks again.

  Monday, April 7, 2014 7:00 PM
• 

  

  0

  Sign in to vote

  I cleared the WU capi2 log and ran a detection which failed. The logs from both are in the zip. I've also included the publisher cert (shouldn't matter but it might help) and the auth cert as requested. The configuration script I use to target the client at the server is also in there.

  https://app.box.com/s/d7244ep5rgm5lt0o50ud

  Monday, April 7, 2014 7:25 PM
• 

  

  0

  Sign in to vote

  Hi David, Thank you for bringing this issue to our attention and for sharing those logs, which have allowed us to reproduce the issue in our test lab. We're testing a fix now, which should fix the issue for you and also prevent others from running into the same problem. We'll have an update to share with you hopefully tomorrow. 

  Ben Herila
  Program Manager, Windows Server

  Tuesday, April 8, 2014 6:43 AM
• 

  

  0

  Sign in to vote

  Interesting..

  When I try it on a not HTTPS protected WSUS it works.

  It looks like it is related to the HTTPS encryption...

  • Proposed as answer by Daniel JiSun Thursday, April 10, 2014 10:28 AM
  • Marked as answer by Daniel JiSun Monday, April 14, 2014 6:01 AM

  Tuesday, April 8, 2014 6:44 AM
• 

  

  1

  Sign in to vote

  Interesting..

  When I try it on a not HTTPS protected WSUS it works.

  It looks like it is related to the HTTPS encryption...

  Disabling SSL is one possible workaround. However, we do recommend that SSL be enabled if possible.

  On Windows Server 2008 R2, you can alternatively enable TLS 1.2. 

  • Marked as answer by Daniel JiSun Monday, April 14, 2014 6:01 AM

  Tuesday, April 8, 2014 7:22 AM
• 

  

  0

  Sign in to vote

  Excellent news. If you want me to test anything let me know, you have my email.

  I'm really hoping the fix doesn't require the whole KB to be uninstalled. I foolishly did a WU cleanup after installation to conserve space on my hyper-v host.

  Tuesday, April 8, 2014 5:37 PM
• 

  

  0

  Sign in to vote

  I think we will be able to release a new update that you will hopefully be able to install on top of the one you already have. Not certain we will do this, but we are trying to make it painless to get back into a good state.

  Tuesday, April 8, 2014 6:48 PM
• 

  

  0

  Sign in to vote

  Just to verify this problem only affects Win 8.1 / 2012 R2 clients pulling from a 2008 R2 WSUS server post KB2919355 correct?  If the WSUS server is 2012 R2 the problem doesn't occur.  Just trying to determine if we should pause roll-out of KB2919355 to wait for fix or not.

  Tuesday, April 8, 2014 7:13 PM
• 

  

  1

  Sign in to vote

  Windows 8.1 Update prevents interaction with WSUS 3.2 over SSL
  - WSUS

  Product Team Blog - Site Home - TechNet Blogs:

  http://blogs.technet.com/b/wsus/archive/2014/04/08/windows-8-1-update-prevents-interaction-with-wsus-3-2-over-ssl.aspx

  *Microsoft plans to issue an update as soon as possible that will
  correct the issue and restore the proper behavior for Windows 8.1
  Update scanning against all supported WSUS configurations. Until that
  time, we are temporarily suspending the distribution of the Windows 8.1
  Update to WSUS servers.*

  You may still obtain the Windows 8.1 Update from the Windows Update
  Catalog or MSDN. However, we recommend that you suspend deployment of
  this update in your organization until we release the update that
  resolves this issue. You may also find the workarounds discussed in
  this article to be useful for testing the Windows 8.1 Update for your
  organization. Thank you for your patience during this time

  ---

  Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

  Tuesday, April 8, 2014 7:41 PM
• 

  

  0

  Sign in to vote

  You can also just turn on TLS 1.2 to be extra sure.

  Tuesday, April 8, 2014 9:05 PM
• 

  

  0

  Sign in to vote

  The only problem I've found is 2012R2 clients and 2008R2 server, and only when using SSL. This is the only configuration that I have available, I can't say whether any others could be affected.

  Given the possibility of rendering large numbers of client systems unpatchable if there is a problem and that the only resolution would be manual intervention it seems prudent to roll the fix into the larger update if possible.

  Tuesday, April 8, 2014 9:14 PM
• 

  

  1

  Sign in to vote

  Hi,

  It’s a good news since we get a workaround. Personally, I think there will be a hotfix if the issue still persists.

  Thursday, April 10, 2014 10:32 AM
• 

  

  0

  Sign in to vote

  and I was wondering why this update didn't show up today in our WSUS3 on '08R2 server. now I know, helpful thread.

  Thursday, April 10, 2014 3:48 PM
• 

  

  0

  Sign in to vote

  I observed that our 2012 R2 Servers are unable to get Microsoft Online updates through our internet proxy when KB2919355 has been installed.

  WindowsUpdatelog:

  2014-04-14	11:49:39:867	 716	9a0	Agent	** START **  Agent: Finding updates [CallerId = AutomaticUpdatesWuApp  Id = 2]
  2014-04-14	11:49:39:867	 716	9a0	Agent	*********
  2014-04-14	11:49:39:867	 716	9a0	Agent	  * Online = Yes; Ignore download priority = No
  2014-04-14	11:49:39:867	 716	9a0	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-04-14	11:49:39:867	 716	9a0	Agent	  * ServiceID = {7971F918-A847-4430-9279-4A52D1EFE18D} Third party service
  2014-04-14	11:49:39:875	 716	9a0	Agent	  * Search Scope = {Machine & All Users}
  2014-04-14	11:49:39:875	 716	9a0	Agent	  * Caller SID for Applicability: S-1-5-21-164184166-1346580952-1231754661-9522
  2014-04-14	11:49:39:894	 716	9a0	SLS	Retrieving SLS response from server...
  2014-04-14	11:49:39:904	 716	9a0	SLS	Making request with URL HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/6.3.9600.0/0?CH=843&L=en-US&P=&PT=0x50&WUA=7.9.9600.17031
  2014-04-14	11:49:45:294	 716	9a0	Misc	WARNING: Send failed with hr = 80072f8f.
  2014-04-14	11:49:45:294	 716	9a0	Misc	WARNING: Proxy List used: <ourproxy.corp.net:8080> Bypass List used : <(null)> Auth Schemes used : <None>
  2014-04-14	11:49:45:294	 716	9a0	Misc	WARNING: Send request failed, hr:0x80072f8f
  2014-04-14	11:49:45:294	 716	9a0	Misc	WARNING: WinHttp: SendRequestUsingProxy failed for <HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/6.3.9600.0/0?CH=843&L=en-US&P=&PT=0x50&WUA=7.9.9600.17031>. error 0x80072f8f
  2014-04-14	11:49:45:295	 716	9a0	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f
  2014-04-14	11:49:45:295	 716	9a0	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f
  2014-04-14	11:49:45:295	 716	9a0	Misc	WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f
  2014-04-14	11:49:45:295	 716	9a0	SLS	FATAL: SLS:CSLSDownloader::GetUrlContent: DoFileDownload failed with 0x80072f8f.
  2014-04-14	11:49:45:295	 716	9a0	SLS	FATAL: GetResponse failed with hresult 0x80072f8f...
  2014-04-14	11:49:45:295	 716	9a0	EP	FATAL: EP: CSLSEndpointProvider::GetWUClientDataAndInitParser - failed to get SLS data, error = 0x80072F8F
  2014-04-14	11:49:45:295	 716	9a0	EP	FATAL: EP: CSLSEndpointProvider::GetEndpointFromSLS - Failed to get client data and init parser, error = 0x80072F8F
  2014-04-14	11:49:45:295	 716	9a0	EP	FATAL: Failed to obtain 9482F4B4-E343-43B6-B170-9A65BC822C77 redir SecondaryServiceAuth URL, error = 0x80072F8F

  
  

  After removing KB2919355 the online update worked fine again!

  Tuesday, April 15, 2014 9:10 AM
• 

  

  0

  Sign in to vote

  Does your proxy support TLS 1.2? It would help if you could tell us what proxy server hardware/software you are using. We are planning to issue a fix to KB2919355 that should fix this problem.

  Tuesday, April 15, 2014 4:11 PM
• 

  

  0

  Sign in to vote

  Few questions:

  1. Repeating Ben's question:
  a. What proxy hardware/software are you using?
  b. What kind of proxy is it, i.e. does it use SSL tunneling or SSL bridging?
  
  2. Do you have any other version of Windows machines (Win8/Win7) behind this same proxy, and are they able to connect to Windows Update server?
  

  3. Is it possible for you to get a Network Monitor trace of the issue?

  Thank you.

  
  

  • Edited by Leo Lie - MSFT Tuesday, April 15, 2014 10:40 PM Clarifying question

  Tuesday, April 15, 2014 8:25 PM
• 

  

  0

  Sign in to vote

  http://blogs.windows.com/windows/b/springboard/archive/2014/04/16/windows-8-1-update-and-wsus-availability-and-adjusted-timeline.aspx

  FYI

  ---

  Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

  Thursday, April 17, 2014 6:30 AM
• 

  

  0

  Sign in to vote

  Hello Microsoft,

  Thank you for providing this fix (KB2959977).

  However this solution is completely a nightmare, because we have now the following situations:

  • You install Win 8.1 without Update (1), WSUS will patch it with the latest revision of KB2919355 => no Problem
  • You install Win 8.1 with Update (1) from the current ISO file => no connection to WSUS
  • A power User manually updated to Update (1) already => no connection to WSUS

  So as described in KB2959977, for new computers you have to:

  Note If you use the volume license media that is provided by Microsoft and that is integrated with the KB 2919355 update to deploy Windows 8.1 or Windows Server 2012 R2, you should apply the KB 2959977 update to the image before you deploy. You can follow the steps in the following Microsoft TechNet topic to apply the KB 2959977 update for Windows 8.1 and Windows Server 2012 R2

  For my environment I would have to run around and manually install KB2959977 on all clients that have Update (1) already installed. Awesome!

  Also for all new computer installations I would have to ensure that the latest revision of Update (1) is used, or KB2959977 gets installed afterwards.

  This is completely unacceptable for my environment.

  I ended up with enabling TLS 1.2 on my Server 2008R2 WSUS:

  SCHANNEL key

  Start Registry Editor (Regedt32.exe), and then locate the following registry key:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

  SCHANNEL\Protocols subkey

  To enable the system to use the protocols that will not be negotiated by default change the DWORD value data of the DisabledByDefault value to 0x0 in the following registry keys under the Protocols key:

  • SCHANNEL\Protocols\TLS 1.2\Client
  • SCHANNEL\Protocols\TLS 1.2\Server

  Well done Microsoft!

  
  
  

  • Edited by St3fan_ Thursday, April 17, 2014 7:46 AM

  Thursday, April 17, 2014 7:44 AM
• 

  

  0

  Sign in to vote

  Hello,

  I tested against the following Proxies:

  Sophos UTM220 V9.109
  Trend Micro IWSVA V5.6
  Websense V7.7

  I now also installed the updated KB 2919355, but still my servers cannot get any updates when checking against Windows Update Online.

  Still the error: Code 80072F8F

  Then I installed KB2959977, but this also did not help.

  Then I uninstalled KB 2919355, but this time Windows Update Online still did not work.

  Then I uninstalled KB 2959977. Now checking against Windows Update Online works again.

  So still (in my view) KB 2919355 and KB 2959977 seem to break something when checking against Windows Updates Online (via proxy). After removing both of the updates, checking updates online (via a proxy) works again.

  I also installed only KB 2959977 on one server and this server then also stopped working to check against Windows Updates Online via proxy. Removing the patch maked it work again.

  So there is something new in all of those patches that breaks Windows Updates via internet proxies.

  Clients (Windows 7) behind the same proxies have no problem to connect to Windows Update
  

  How can I send a Network Monitor Trace to you?

  • Edited by MS-Wing Thursday, April 17, 2014 7:43 PM

  Thursday, April 17, 2014 7:56 AM
• 

  

  0

  Sign in to vote

  Same situation here:

  the new released update KB 2959977 does not fix the problem, still error: Code 80072F8F

  After uninstalling KB 2959977 and KB 2919355 my clients can connect again to my wsus server.So there is really something wrong and it's not the solution to install KB 2959977.

  I think in the moment, the only solution is to enable TLS on the wsus server (2008 R2).

  Thursday, April 17, 2014 11:35 AM
• 

  

  0

  Sign in to vote

  I now tested to do Microsoft Online Update on the servers that fail to connect to Microsoft Update after installing KB2959977/KB 2919355  by directly natting them to the internet - No https-proxy involved. This works!

  So currently KB2959977/KB2919355 break Windows Online update via http/https proxies as I see it.

  Again: My problem is not with the internal WSUS Server, but with the official update servers from Microsoft accessed by industry standard proxies! (Not transparent ones, but the http proxies you enter in Internet Explorer configuration (IP Number and Port)).

  • Edited by MS-Wing Thursday, April 17, 2014 7:43 PM

  Thursday, April 17, 2014 1:01 PM
• 

  

  0

  Sign in to vote

  Our WSUS pulled the latest update (KB2919355) for 8/2012 machines, it installed at scheduled lunch time. After restart machines were still able to connect to update services, locally or directly to MS, there was 1 more 2MB update after that. Seems to be working ok here, but we don't use any proxies.

  Thursday, April 17, 2014 9:29 PM
• 

  

  0

  Sign in to vote

  Hello,

  I'm sorry for my delayed response. Here are the instructions on how to get Network Monitor trace, along with other stuffs that I will need:

  1. Enable WU verbose logging on machine:
    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace /v Flags /d 22 /t REG_DWORD /f
    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace /v Level /d 4 /t REG_DWORD /f
    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace\DtaStor /v LogFile /d "C:\windows\WU_datastore.log" /t REG_SZ /f
  2. Enable CAPI2 logging from Event Viewer:
    a. Open 'Event Viewer'
    b. Browse to 'Application and Services Logs' > Microsoft > Windows > CAPI2 > Operational.
    c. Right click on 'Operational' in the directory tree, and select 'Enable log'
  3. Install Network Monitor. Run it as administrator and select “New capture” and hit Start.
  4. Check for updates on WU.
  5. Hit stop on Network Monitor and save the traces.
  6. Go back to Event Viewer and export CAPI2 events by clicking “Save All Events as …”
  7. Share the NetMon traces, CAPI2 events, and windowsupdate.log with us.

  You can zip them all up and place the file on file sharing site like OneDrive. Thank you very much!

  Wednesday, April 23, 2014 2:02 AM
• 

  

  1

  Sign in to vote

  Hello,

  About the problem with KB2919355 and Microsoft Online Update via http-proxies:

  Before doing all this network monitor stuff, I decided to try something else:
  I removed one of the problematic servers from the domain and I could check for Online Updates via Proxy again!

  So currently I nailed down the problem to only occur, if you have WSUS-Group Policy settings defined and applied to the OU where the servers are placed. If I move a problematic server out of the OU to another OU without WSUS Group Policy, the problem with error 80072F8F while doing Microsoft Online Update Check does NOT appear.

  Still the problem is not easy to trace, as I have another server that does not have this problem. I am still trying to find the exact cause for this behaviour. But at least I know that when the error occurs, it has definately to do with WSUS-Group Policy being applied and KB2919355 being installed.

  This is how the Windowsupdate.log looks like on a server without the problem and KB2919355 installed:

  2014-04-23	10:20:27:268	 792	b00	Agent	  * Online = Yes; Ignore download priority = No
  2014-04-23	10:20:27:268	 792	b00	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-04-23	10:20:27:268	 792	b00	Agent	  * ServiceID = {7971F918-A847-4430-9279-4A52D1EFE18D} Third party service
  2014-04-23	10:20:27:268	 792	b00	Agent	  * Search Scope = {Machine & All Users}
  2014-04-23	10:20:27:268	 792	b00	Agent	  * Caller SID for Applicability: S-1-5-21-164184166-1346580952-1231754661-9522
  2014-04-23	10:20:27:268	 792	b00	EP	Got 9482F4B4-E343-43B6-B170-9A65BC822C77 redir SecondaryServiceAuth URL: "7971f918-a847-4430-9279-4a52d1efe18d"
  2014-04-23	10:20:27:268	 792	b00	EP	Got 7971F918-A847-4430-9279-4A52D1EFE18D redir Client/Server URL: "https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx"
  2014-04-23	10:20:27:268	 792	b00	Setup	Checking for agent SelfUpdate
  2014-04-23	10:20:27:268	 792	b00	Setup	Client version: Core: 7.9.9600.17031  Aux: 7.9.9600.17031
  2014-04-23	10:20:27:268	 792	b00	EP	Got 9482F4B4-E343-43B6-B170-9A65BC822C77 redir SelfUpdate URL: "https://fe2.update.microsoft.com/v10/3/windowsupdate/selfupdate"

  
  

  This is how the Windowsupdate.log looks like on a server with the problem and KB2919355 installed:

  2014-04-23	10:21:54:042	 752	47c	Agent	  * Online = Yes; Ignore download priority = No
  2014-04-23	10:21:54:042	 752	47c	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-04-23	10:21:54:042	 752	47c	Agent	  * ServiceID = {7971F918-A847-4430-9279-4A52D1EFE18D} Third party service
  2014-04-23	10:21:54:042	 752	47c	Agent	  * Search Scope = {Machine & All Users}
  2014-04-23	10:21:54:042	 752	47c	Agent	  * Caller SID for Applicability: S-1-5-21-164184166-1346580952-1231754661-9522
  2014-04-23	10:21:54:042	 752	47c	SLS	Retrieving SLS response from server using ETAG "hKnjujWw8qNxmyhQqGtJKf9fHd1QtUzyEI6M7V4AWQw=_1440"...
  2014-04-23	10:21:54:042	 752	47c	SLS	Making request with URL HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/6.3.9600.0/0?CH=385&L=en-US&P=&PT=0x50&WUA=7.9.9600.17092
  2014-04-23	10:22:02:145	 752	47c	Misc	WARNING: Send failed with hr = 80072f8f.
  2014-04-23	10:22:02:145	 752	47c	Misc	WARNING: Proxy List used: <192.168.250.4:7432> Bypass List used : <<local>> Auth Schemes used : <None>
  2014-04-23	10:22:02:145	 752	47c	Misc	WARNING: Send request failed, hr:0x80072f8f
  2014-04-23	10:22:02:145	 752	47c	Misc	WARNING: WinHttp: SendRequestUsingProxy failed for <HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/6.3.9600.0/0?CH=385&L=en-US&P=&PT=0x50&WUA=7.9.9600.17092>. error 0x80072f8f
  2014-04-23	10:22:02:145	 752	47c	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f
  2014-04-23	10:22:02:145	 752	47c	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f
  2014-04-23	10:22:02:145	 752	47c	Misc	WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f

  It is interesting to note that the problematic servers run to a URL of HTTPS://sls.update.microsoft.com.

  This is totally different to the "good"-servers that first run to https://fe2.update.microsoft.com

  Remember that both servers are running to the same http-proxy. Both have NO direct connection or nat-connection to the internet.
  

  Update: In the meantime I installed a fresh new VM from the latest 2012 R2 Standard iso from volume licensing web site, put it into the domain to my servers OU (that also has the WSUS Group Policy Settings applied) and installed the latest updates that were offered by our local WSUS installations. Rebooted the machine again and got error Code 80072F8F when checking for Microsoft Updates Online.

  So, all in all I have currently 3 Server with the problem and 1 without the problem. I cannot really understand why the particular server without the problem works correctly actually. As you can read from above, a fresh new installed VM immediately gets the problem I described.
  
  

  • Edited by MS-Wing Wednesday, April 23, 2014 4:44 PM

  Wednesday, April 23, 2014 8:11 AM
• 

  

  0

  Sign in to vote

  Oddly, I get the 80072F8F error when I try to update via my WSUS server.  When I go to the WU/MU site I have no trouble, so this problem is opposite yours.  My proxy server is TMG. 

  Note that this only applies to the Control Panel applet method of checking for updates.  If I run "wuauclt /detectnow" there are no problems contacting WSUS.

  I've installed the revised KB2919355 on four Windows 8.1 machines now and all of them have this problem.  In my case I'm not too worried about it since it won't keep my machines from getting patched, but I would like to know what is causing the issue.

  The next time I'm in a position to shut down the TMG server, I'll try updating with the WSUS server again to see if that is causing the problem.
  

  Thursday, April 24, 2014 1:54 AM
• 

  

  0

  Sign in to vote

  I shut down the TMG server, ran the check for updates from the Control Panel applet and the client was then able to update with the WSUS server on the LAN.

  Here is a summary so that someone from MS can try to figure out why this is happening:

  - Proxy server is TMG 2010 fully updated/patched

  - Proxy, WSUS, and clients are all on the same subnet

  - The 80072F8F error doesn't happen until after KB2919355 is installed

  - This error only occurs when trying to update from the WSUS server using the Control Panel applet

  - Choosing to update from the WU/MU site using the Control Panel applet is successful

  - Allowing the client to update itself on schedule from the WSUS server is successful, as is running "wuauclt /detectnow"

  - The WSUS server is using port 8531 as the SSL port.  The TMG server was set long ago to allow that port as an SSL port.  (The TMG clients should be bypassing the proxy for local destinations anyway.)

  - When I shut down the TMG server, there was no way for the clients to get to the Internet, so at that point it would be impossible for them to get updates from anything but the WSUS server

  I can post a WindowsUpdate log if needed.

  Friday, April 25, 2014 2:23 PM
• 

  

  0

  Sign in to vote

  Hi MS-Wing,

  1. Is the proxy server the same for both working and non-working OU?
  2. If they are not the same, are they blacklisting/whitelisting the same set of hosts?
  3. Are they following the recommendation in http://support.microsoft.com/kb/885819/en-us, especially *.windowsupdate.com?
  4. If they are not, would you please whitelist all the URLs in that KB, wait for say 30 mins, and try checking for updates again?
  
  We are actively investigating this, and have an idea of what's happening. However, we don't have anything to share publicly yet. We apologize for the inconvenience, and are thankful for your help so far.

  Friday, April 25, 2014 5:17 PM
• 

  

  0

  Sign in to vote

  Hi CFS3rd, would you please share windowsupdate.log? Thank you.

  Friday, April 25, 2014 5:24 PM
• 

  

  0

  Sign in to vote

  Thanks for the reply.

  I don't have a working OU and a non-working OU.  All Windows 8.1 machines with the Update installed are experiencing the problem.  Only one proxy server is used by them all.

  I'm don't think points 2,3 or 4 relate to my situation.  I am having no trouble contacting *.windowsupdate.com.  I am having trouble updating from the local WSUS server (only when using the Control Panel applet).

  Friday, April 25, 2014 8:17 PM
• 

  

  0

  Sign in to vote

  Hi CFS3rd,

  Sorry, the OU discussion and the 4 points were specifically for MS-Wing. For your case, I would need windowsupdate.log to get started. Also, is your WSUS SSL cert self-signed (generated through IIS) or is it something fancier (with CAs and CRL revocation URL embedded)?

  Thank you.

  Friday, April 25, 2014 8:22 PM
• 

  

  0

  Sign in to vote

  Hello Leo Lie,

  here are my answers:

  1. Is the proxy server the same for both working and non-working OU?
  -> Yes

  3. Are they following the recommendation in http://support.microsoft.com/kb/885819/en-us,especially *.windowsupdate.com?
  -> Yes, this recommendation is followed. In fact the *.windowsupdate.com site was excluded from Antivirus/Filtering/Authentication by the Proxy-Vendor by default. As Windows 2008 R2 Servers or Windows 7 Clients have no issues to get windowsupdates from that proxy, I can only repeat that this only happens to the 2012 R2 servers in the server OU (with the WSUS Group Policy) that have kb2919355 applied. Excluding the one exceptional server that does NOT have the issue, although kb2919355 is installed...

  Hope you find the cause soon. If you need anything else, just tell me.

  
  

  • Edited by MS-Wing Friday, April 25, 2014 8:44 PM

  Friday, April 25, 2014 8:43 PM
• 

  

  0

  Sign in to vote

  Okay, thanks.

  The SSL cert is from a local AD-integrated CA.  All clients are AD members so they automatically trust the cert.  The CRL revocation, etc. is embedded and correct.

  Here is part of the WindowsUpdate log.  I separated it into sections with gaps in between.  The first section is when I tried to update from the local WSUS server using the Control Panel applet and failed.  The second section is the successful attempt to update from the MS update site via the Control Panel applet.  The third section shows the successful connection to the local WSUS server when running "wuauclt /dectectnow":

  https://onedrive.live.com/redir?resid=6B54F90D34A444CA!705&authkey=!ADItYoo5TGmSLME&ithint=file%2c.txt

  Monday, April 28, 2014 4:00 AM
• 

  

  0

  Sign in to vote

  Okay, thanks.

  The SSL cert is from a local AD-integrated CA.  All clients are AD members so they automatically trust the cert.  The CRL revocation, etc. is embedded and correct.

  Here is part of the WindowsUpdate log.  I separated it into sections with gaps in between.  The first section is when I tried to update from the local WSUS server using the Control Panel applet and failed.  The second section is the successful attempt to update from the MS update site via the Control Panel applet.  The third section shows the successful connection to the local WSUS server when running "wuauclt /dectectnow":

  https://onedrive.live.com/redir?resid=6B54F90D34A444CA!705&authkey=!ADItYoo5TGmSLME&ithint=file%2c.txt

  Hi CFS3rd,

  Thank you for sharing your logs. The failure occured when WU was trying to establish SSL connection to download wuident.cab from WSUS server. This cab is only downloaded when a scan is triggered by our UI or scheduler. "wuauclt /detectnow" doesn't do that, which explains why your third attempt was working.

  Would you please confirm that all the CRL URLs from WSUS certificate are accessible from your client machine? When WSUS is configured over SSL, WU does a hard-fail on any revocation check failure when downloading wuident.cab. This can be caused by the URLs being offline or blocked by proxy/firewall. Normally the error code is 0x80072F8F, instead of 0x80072EF3 in your case, hence I wasn't too sure until I learn more.

  If the URLs are accessible, it would be great if you can help us collect more data:

  1. Start network tracing by running this command as admin:
  netsh trace start scenario=InternetClient
  
  2. Enable CAPI2 logging from Event Viewer:
    a. Open 'Event Viewer'
    b. Browse to 'Application and Services Logs' > Microsoft > Windows > CAPI2 > Operational.
    c. Right click on 'Operational' in the directory tree, and select 'Enable log'

  3. Scan against WSUS using Control Panel applet and let if fail.
  

  4. Run this command as admin, and it will produce a NetTrace.cab file:
  netsh trace stop

  5. Go back to Event Viewer and export CAPI2 events by clicking “Save All Events as …”

  6. Please share the nettrace.cab, CAPI2 events, and windowsupdate.log

  Thank you again.

  Monday, April 28, 2014 9:27 PM
• 

  

  0

  Sign in to vote

  Hello Leo Lie,

  here are my answers:

  1. Is the proxy server the same for both working and non-working OU?
  -> Yes

  3. Are they following the recommendation in http://support.microsoft.com/kb/885819/en-us,especially *.windowsupdate.com?
  -> Yes, this recommendation is followed. In fact the *.windowsupdate.com site was excluded from Antivirus/Filtering/Authentication by the Proxy-Vendor by default. As Windows 2008 R2 Servers or Windows 7 Clients have no issues to get windowsupdates from that proxy, I can only repeat that this only happens to the 2012 R2 servers in the server OU (with the WSUS Group Policy) that have kb2919355 applied. Excluding the one exceptional server that does NOT have the issue, although kb2919355 is installed...

  Hope you find the cause soon. If you need anything else, just tell me.

  
  

  Hi MS-Wing,

  Thank you for the information. What we have known so far is that blocking access to ctldl.windowsupdate.com will cause SSL certificate revocation check to fail. With KB2919355 onwards, we do a hard-fail when that check fails. If it's possible, I would need the following data from you:
  

  1. Start network tracing by running this command as admin:
  netsh trace start scenario=InternetClient
  
  2. Enable CAPI2 logging from Event Viewer:
    a. Open 'Event Viewer'
    b. Browse to 'Application and Services Logs' > Microsoft > Windows > CAPI2 > Operational.
    c. Right click on 'Operational' in the directory tree, and select 'Enable log'

  3. Scan against public Windows Update using UI (Control Panel applet or PC Settings) and let it fail.

  4. Run this command as admin, and it will produce a NetTrace.cab file:
  netsh trace stop

  5. Go back to Event Viewer and export CAPI2 events by clicking “Save All Events as …”

  6. Please share the nettrace.cab, CAPI2 events, and windowsupdate.log

  Thank you again.

  Monday, April 28, 2014 9:42 PM
• 

  

  0

  Sign in to vote

  The URLs in the certificate shouldn't be the culprit because this is only affecting Windows 8.1 after the Update is installed.  Other versions of Windows on my network are successful when checking for updates from the WSUS server via the Control Panel.  Anyway, I checked on the CAs using the Enterprise PKI snapin and every one of them is listed as OK.

  I'll send the requested data if there's a way to get it to you without posting it publicly.

  Thanks.

  Tuesday, April 29, 2014 2:54 AM
• 

  

  0

  Sign in to vote

  The URLs in the certificate shouldn't be the culprit because this is only affecting Windows 8.1 after the Update is installed.  Other versions of Windows on my network are successful when checking for updates from the WSUS server via the Control Panel.  Anyway, I checked on the CAs using the Enterprise PKI snapin and every one of them is listed as OK.

  I'll send the requested data if there's a way to get it to you without posting it publicly.

  Thanks.

  
  Hi there, you can share the files with wutest1 [at} outlook.com either using email or OneDrive. Thank you!

  Tuesday, April 29, 2014 5:34 AM
• 

  

  0

  Sign in to vote

  Hello Leo Lie,

  as you mentioned this certificate check, I now also have an idea why there is that one particular server I have that does NOT have the issue with KB 2919355:

  During my investigations, I once used NAT to get this server to the internet (more or less) directly. So I think this direct internet connection enabled the server to get the CRL and cache it locally.

  So, when I then reconfigured the server as my other servers (no public DNS resolution, no gateway to the internet router, putting proxy settings into internet explorer), this server is now able to check for the revoked certificates using this local cached CRL (I guess...).

  But interestingly enough this "CRL-check" seems only to be implemented when WSUS-Group Policy Settings have been applied, as the problem does not occur, when WSUS Group Policies are not in place.

  I shared the log files on onedrive with the email address you suggested above.
  
  
  

  • Edited by MS-Wing Tuesday, April 29, 2014 2:50 PM

  Tuesday, April 29, 2014 2:41 PM
• 

  

  0

  Sign in to vote

  Hello Leo Lie,

  as you mentioned this certificate check, I now also have an idea why there is that one particular server I have that does NOT have the issue with KB 2919355:

  During my investigations, I once used NAT to get this server to the internet (more or less) directly. So I think this direct internet connection enabled the server to get the CRL and cache it locally.

  So, when I then reconfigured the server as my other servers (no public DNS resolution, no gateway to the internet router, putting proxy settings into internet explorer), this server is now able to check for the revoked certificates using this local cached CRL (I guess...).

  But interestingly enough this "CRL-check" seems only to be implemented when WSUS-Group Policy Settings have been applied, as the problem does not occur, when WSUS Group Policies are not in place.

  I shared the log files on onedrive with the email address you suggested above.
  
  
  

  Thank you so much for sending us the logs! Your guess is correct that we do actually cache CRLs. CRL check is however turned on for all scenarios, with or without WSUS. Furthermore, starting with KB2919355, we abort the connection when revocation check fails. This is why you will only see it on Windows 8.1 with KB2919355 installed.

  Now the details that are specific to your logs. Your issue is indeed caused by revocation check failure. Your DNS server was not responding to a resolution request for a hostname where the CRL is hosted (name-to-IP address translation).
  

  869         4:25:56 PM 4/29/2014      7:25:56 AM 4/29/2014      11.6587737          (792)     WEBIO_MicrosoftWindowsWebIO                WEBIO_MicrosoftWindowsWebIO:0x00000000A7821010: Name Resolution Request (Name www.microsoft.com/pkiops/crl/Microsoft%20Update%20Secure%20Server%20CA%202.1.crl ) (Timeout 0 (0x0)) (CompletionContext: 986414220704 (0xE5AADE85A0))

  939         4:25:56 PM 4/29/2014      7:25:56 AM 4/29/2014      11.6864677          (912)     DNSClient_MicrosoftWindowsDNSClient                DNSClient_MicrosoftWindowsDNSClient:Name resolution for the name www.microsoft.com timed out after the DNS server 192.168.250.59:53 did not respond.

  Your other DNS server is behaving the same way as well:

  1044       4:25:57 PM 4/29/2014      7:25:57 AM 4/29/2014      12.7013308          (912)     DNSClient_MicrosoftWindowsDNSClient                DNSClient_MicrosoftWindowsDNSClient:Name resolution for the name www.microsoft.com timed out after the DNS server 192.168.250.60:53 did not respond.

  Also, do you have "Turn off Automatic Root Update" policy enabled? http://support.microsoft.com/kb/909561. It's not a problem, I'd just like to confirm. Normally we go to ctldl.windowsupdate.com for revocation check unless that policy is enabled.

  Thank you again.

  Tuesday, April 29, 2014 11:31 PM
• 

  

  0

  Sign in to vote

  Hello Leo Lie,

  we do not have "Turn off Automatic Root Update" policy enabled.
  But from my experience I know that this Automatic Update will require public DNS resolution and direct internet connectivity (without a proxy). So this will never work on our internal environment.

  We have a quite common enterprise setup here:

  The internal servers cannot do ANY public DNS name resolution.
  They can only connect via the http/https proxy to the internet.
  So in this case it is totally normal that they cannot resolve that name.
  

  Is there some magic regkey I can set to get to the old behaviour again, or will you issue a patch/hotfix?

  The issue is not so big, when you just rely on your internal WSUS Server to deliver the updates, but occasionally I like to check the updates via Microsoft Online Update to install some updates that have not been approved on the WSUS or to check for other product categories that are not offered via our WSUS.

  So, for us it is really important that everything works as before the patch without this weird 0x80072F8F error.

  
  

  • Edited by MS-Wing Wednesday, April 30, 2014 8:38 AM

  Wednesday, April 30, 2014 8:37 AM
• 

  

  0

  Sign in to vote

  Hello Leo Lie,

  we do not have "Turn off Automatic Root Update" policy enabled.
  But from my experience I know that this Automatic Update will require public DNS resolution and direct internet connectivity (without a proxy). So this will never work on our internal environment.

  We have a quite common enterprise setup here:

  The internal servers cannot do ANY public DNS name resolution.
  They can only connect via the http/https proxy to the internet.
  So in this case it is totally normal that they cannot resolve that name.
  

  Is there some magic regkey I can set to get to the old behaviour again, or will you issue a patch/hotfix?

  The issue is not so big, when you just rely on your internal WSUS Server to deliver the updates, but occasionally I like to check the updates via Microsoft Online Update to install some updates that have not been approved on the WSUS or to check for other product categories that are not offered via our WSUS.

  So, for us it is really important that everything works as before the patch without this weird 0x80072F8F error.

  
  

  Hi MS-Wing,

  We would like to understand your setup better before we proceed.

  First, the revocation check isn't doing anything fancy. It was simply trying to download a file from www.microsoft.com through HTTP. It goes through DNS because the IP address has not ever been resolved before. In our testing, it could work through proxy. It shouldn't really need a public DNS, as long as the internal DNS server can return the correct IP.

  Second, how could your machine resolve *.update.microsoft.com and *.windowsupdate.com, but NOT www.microsoft.com? Is it because the DNS server has entries for those, but just not www.microsoft.com?

  Third, in our testing, we only see revocation check going to ctldl.windowsupdate.com instead of www.microsoft.com. The only time it went to www.microsoft.com in our testing was when we turned on the root update policy. Would you please tell us what you see in: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot?

  Thank you very much for your continued help.

  Wednesday, April 30, 2014 5:18 PM
• 

  

  0

  Sign in to vote

  Hello Leo Lie,
  
  our internal DNS Servers cannot resolve any public ip addresses and we also do not have any manual defined *microsoft.com zones on them. We also do not forward unresolvable queries to DNS Servers that can resolve public IP Addresses. The only server that can resolve public IP Addresses is the proxy server itself (192.168.250.6).
  
  I do not think that our servers could resolve *.update.microsoft.com or *.windowsupdate.com via DNS queries, because as described above setup, this is simply not possible in our setup. (This was of course possible during a short time frame, where I used nat/masquerading to experiment with direct connection to the internet and where I also entered the ip of our proxy as a dns server, as this proxy can forward the dns requests to a server that can do public dns ip resolution). So, if you see any successful resolution of public dns ip addresses of microsoft.com in my logs, it is from these experiments.
  
  In order to simulate our environment you really have to have a setup, where no public DNS name resolution is possible for the internal servers (only their internal AD-Zones should be in DNS as a minimum). The only server that can reach the internet should be a http/https proxy (TMG for example) that is entered into the Internet Explorer Proxy Settings of the internal servers that need to contact the internet.
  
  In HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot:
  DisableRootAutoUpdate is set to 1
  
  I checked our Group Policy and indeed on our server OUs, we have disabled this Update, because our servers cannot directly speak to the internet and the automatic root updates does not work via proxies. At least on our 2003 Servers I remember getting error messages in the eventlog, if we do not disable this autoupdate. And in the end it is also a bit logical that this autoupdate cannot work via proxy. Because the internet explorer proxy settings is a per user setting. But the service starts of course in its own context, so it does not know anything about a proxy.
  
  
  
  
  
  

  • Edited by MS-Wing Thursday, May 1, 2014 3:03 PM

  Thursday, May 1, 2014 11:13 AM
• 

  

  0

  Sign in to vote

  Hello Leo Lie,
  
  our internal DNS Servers cannot resolve any public ip addresses and we also do not have any manual defined *microsoft.com zones on them. We also do not forward unresolvable queries to DNS Servers that can resolve public IP Addresses. The only server that can resolve public IP Addresses is the proxy server itself (192.168.250.6).
  
  I do not think that our servers could resolve *.update.microsoft.com or *.windowsupdate.com via DNS queries, because as described above setup, this is simply not possible in our setup. (This was of course possible during a short time frame, where I used nat/masquerading to experiment with direct connection to the internet and where I also entered the ip of our proxy as a dns server, as this proxy can forward the dns requests to a server that can do public dns ip resolution). So, if you see any successful resolution of public dns ip addresses of microsoft.com in my logs, it is from these experiments.
  
  In order to simulate our environment you really have to have a setup, where no public DNS name resolution is possible for the internal servers (only their internal AD-Zones should be in DNS as a minimum). The only server that can reach the internet should be a http/https proxy (TMG for example) that is entered into the Internet Explorer Proxy Settings of the internal servers that need to contact the internet.
  
  In HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot:
  DisableRootAutoUpdate is set to 1
  
  I checked our Group Policy and indeed on our server OUs, we have disabled this Update, because our servers cannot directly speak to the internet and the automatic root updates does not work via proxies. At least on our 2003 Servers I remember getting error messages in the eventlog, if we do not disable this autoupdate. And in the end it is also a bit logical that this autoupdate cannot work via proxy. Because the internet explorer proxy settings is a per user setting. But the service starts of course in its own context, so it does not know anything about a proxy.
  

  This makes sense now; I'm able to replicate your setup and seeing what you're seeing : )

  Can you try setting the machine level (WinHTTP) proxy too? There are two ways to do this, just run either of these commands as admin:

  1. netsh winhttp set proxy your_proxy_server "<Local>;hostname_that_you_want_to_bypass_if_any"
  

  2. Or after you've already set the proxy in IE Internet Options:
  netsh winhttp import proxy source=ie

  You can leave all of your other setup as is. Please let us know if that allows you to connect to WU in your environment. Thank you.

  • Proposed as answer by MS-Wing Friday, May 2, 2014 9:47 AM

  Thursday, May 1, 2014 10:02 PM
• 

  

  0

  Sign in to vote

  Diagnostic information sent.

  Thanks.

  Friday, May 2, 2014 2:39 AM
• 

  

  0

  Sign in to vote

  Leo Lie,

  I issued the command "netsh winhttp import proxy source=ie" and rebooted the server.

  This made the error 0x80072F8 go away and I can now successfully check for online updates AND for local wsus updates! Thanks for the good hint!

  Maybe you do a KB Article about this issue? Just setting blindly the winhttp proxy might not be good idea in scenarios where the proxy needs authentication....

  In our case your suggested fix works fine!
  
  
  

  • Edited by MS-Wing Friday, May 2, 2014 2:05 PM

  Friday, May 2, 2014 9:46 AM
• 

  

  0

  Sign in to vote

  Diagnostic information sent.

  Thanks.

  Hi CFS3rd,

  Thank you for sending us the data. We looked at two windowsupdate.log that you sent us, and we didn't see any 0x80072F8F error. You were however consistently hitting a different error, 0x80072EF3. It seems to be caused by proxy server. You mentioned that your client should be bypassing proxy for local destinations, but that doesn't seem to be happening. Client was trying to connect to WSUS server over a proxy, and the proxy didn't response to our CONNECT request with an OK (HTTP 200).

  "The WSUS server is using port 8531 as the SSL port.  The TMG server was set long ago to allow that port as an SSL port.  (The TMG clients should be bypassing the proxy for local destinations anyway.)"

  When WU queried for presence of a proxy, we got a proxy back with no bypass:
  proxy = perimeter2.nameRedacted.com:8080, bypass = <NULL>
  

  So WU tried to connect to WSUS through proxy:
  1989 9:50:08 PM 5/1/2014  (984) WEBIO_MicrosoftWindowsWebIO WEBIO_MicrosoftWindowsWebIO:0x0000000072B24080: Sending Headers: CONNECT nameRedacted-sysctr2.nameRedacted.com:8531 HTTP/1.1
  How is your proxy set on the client side? IE Options, TMG Client, WPAD, or combination of those? We believe "wuauclt /detectnow" worked in your case because that operation relied on machine-level/WinHTTP proxy setting, which was not configured on your machine, i.e. direct access. However, when you did a scan from Control Panel applet, we were using user-level proxy.
  
  We were able to replicate what you're seeing when we removed the bypass from our proxy setup, and TMG returned 502 Bad Gateway to client. Hope this helps.
  

  Friday, May 2, 2014 8:22 PM
• 

  

  0

  Sign in to vote

  I didn't notice that I was getting different error codes on different machines, but the bad results are the same either way.  I have the same problem on two different test networks, by the way.
  

  Keep in mind that despite the fact that the problem is related to the TMG server, it *only affects Windows 8.1 with the Update installed*.  No Windows 8.1 machines were having this problem before installing the update.

  Here are snippets from two different Windows 8.1 machines' Windows Update logs (different network that the last log)  There was nothing in the log that said "bypass = <NULL>":

  2014-05-02    23:17:34:360     936    538    Misc    WARNING: Proxy List used: <microbe-isa1:8080> Bypass List used : <<local>> Auth Schemes used : <None>
  2014-05-02    23:17:34:360     936    538    Misc    WARNING: Send request failed, hr:0x80072f8f
  2014-05-02    23:17:34:360     936    538    Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <https://microbe-vmm2.removed.com:8531/selfupdate/wuident.cab>. error 0x80072f8f
  2014-05-02    23:17:34:360     936    538    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f
  2014-05-02    23:17:34:360     936    538    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f
  2014-05-02    23:17:34:360     936    538    Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f
  2014-05-02    23:17:34:360     936    538    Misc    WARNING: Send failed with hr = 80072f8f.
  
  
  
  2014-05-02    22:57:22:086     920    c04    Misc    WARNING: Proxy List used: <microbe-isa1:8080> Bypass List used : <<local>> Auth Schemes used : <None>
  2014-05-02    22:57:22:086     920    c04    Misc    WARNING: Send request failed, hr:0x80072f8f
  2014-05-02    22:57:22:086     920    c04    Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <https://microbe-vmm2.removed.com:8531/selfupdate/wuident.cab>. error 0x80072f8f
  2014-05-02    22:57:22:086     920    c04    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f
  2014-05-02    22:57:22:086     920    c04    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f
  2014-05-02    22:57:22:086     920    c04    Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f
  2014-05-02    22:57:22:101     920    c04    Misc    WARNING: Send failed with hr = 80072f8f.

  Here's a snippet from a Windows 8 machine when I successfully updated from the WSUS server.  There is no reference to a proxy at all:

  2014-05-02    23:55:22:352     900    a9c    EP    Got WSUS Client/Server URL: "https://microbe-vmm2.removed.com:8531/ClientWebService/client.asmx"
  2014-05-02    23:55:22:368     900    a9c    Setup    Checking for agent SelfUpdate
  2014-05-02    23:55:22:368     900    a9c    Setup    Client version: Core: 7.8.9200.16731  Aux: 7.8.9200.16731
  2014-05-02    23:55:22:368     900    a9c    EP    Got WSUS SelfUpdate URL: "https://microbe-vmm2.removed.com:8531/selfupdate"
  2014-05-02    23:55:22:368     900    a9c    Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab

  I use WPAD and and the Firewall Client.  If I do nslookup on "wpad" it returns the TMG server as it should. Here's a screen shot of the Proxy settings on an affected Windows 8.1 machine, where you can see it says to bypass for local addresses.  I did not set this manually, it's set by the client:

  

  So why does only Windows 8.1 with the Update have this problem with TMG?

  Saturday, May 3, 2014 4:19 AM
• 

  

  0

  Sign in to vote

  Hi CFS3rd,

  Your observation is correct that only Windows 8.1 with KB2919355 is having problem with this. With this update, we added a security feature to enable online revocation checking to ensure we can stop trusting a certificate as soon as it's revoked by its issuer. Unfortunately, we are now learning all kinds of network setup that will cause this feature to fail. We are truly sorry for the inconvenience, and thank you for your continued help.

  MS-Wing helped us understand one setup, and we'd love to understand yours too. Please kindly collect the data from the machine that's hitting 0x80072F8F against WSUS server. I'm copying the instructions below for your reference (with additional step #0):
  

  0. Clear revocation caches by running these commands as admin:

   certutil.exe -urlcache * delete
   reg delete "HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate" /v DisallowedCertEncodedCtl /f
   reg delete "HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate" /v DisallowedCertLastSyncTime /f
   certutil.exe -setreg chain\ChainCacheResyncFiletime @now
   net stop cryptsvc
   Net stop wuauserv
    ipconfig /flushdns

  1. Start network tracing by running this command as admin:
     netsh trace start scenario=InternetClient

  2. Enable CAPI2 logging from Event Viewer:
     a. Open 'Event Viewer'
     b. Browse to 'Application and Services Logs' > Microsoft > Windows > CAPI2 > Operational.
     c. Right click on 'Operational' in the directory tree, and select 'Enable log'

  3. Scan against public Windows Update using UI (Control Panel applet or PC Settings) and let it fail.

  4. Run this command as admin, and it will produce a NetTrace.cab file:
     netsh trace stop

  5. Go back to Event Viewer and export CAPI2 events by clicking “Save All Events as …”

  6. Please share the nettrace.cab, CAPI2 events, and windowsupdate.log

  Thank you.

  Tuesday, May 6, 2014 3:13 AM
• 

  

  0

  Sign in to vote

  Hi

  I have sent a set of logs to wutest1 [at} outlook.com.
  I have the same problem with WSUS and 80072F8F on my test servers.

  The first two attempts were against WSUS (failed), the last attempt against WU (successful)

  From the CAPI2 log it seems that the revocation check fails. Yet, from that same server, I can browse to the CRL and view it.

  Thanks for any insight :)

  ---

  www.quadrotech-it.com - All your Enterprise Vault / Exchange / PST Migration Tools

  Tuesday, May 6, 2014 5:19 AM
• 

  

  0

  Sign in to vote

  Hi

  I have sent a set of logs to wutest1 [at} outlook.com.
  I have the same problem with WSUS and 80072F8F on my test servers.

  The first two attempts were against WSUS (failed), the last attempt against WU (successful)

  From the CAPI2 log it seems that the revocation check fails. Yet, from that same server, I can browse to the CRL and view it.

  Thanks for any insight :)

  ---

  www.quadrotech-it.com - All your Enterprise Vault / Exchange / PST Migration Tools

  Hi MichelZ, your case is different from others. It was an actual, non-network related, revocation failure. There seems to be a misconfiguration on either the certificate or CRL. Presence of event 42 with error on Call_CertIsValidCRLForCertificate indicates that "IDP in the CRL is Not Valid for the Subject Certificate". See http://technet.microsoft.com/en-us/library/cc749296(v=ws.10).aspx.
  
  Our guess is that the Certificate Distribution Point (CDP) field in your end/leaf cert does not contain the same URL as the one in CRL's Issuing Distribution Point (IDP) field. Hope this helps. Thank you.

  Wednesday, May 7, 2014 2:11 AM
• 

  

  0

  Sign in to vote

  Hi MichelZ, your case is different from others. It was an actual, non-network related, revocation failure. There seems to be a misconfiguration on either the certificate or CRL. Presence of event 42 with error on Call_CertIsValidCRLForCertificate indicates that "IDP in the CRL is Not Valid for the Subject Certificate". See http://technet.microsoft.com/en-us/library/cc749296(v=ws.10).aspx.
  
  Our guess is that the Certificate Distribution Point (CDP) field in your end/leaf cert does not contain the same URL as the one in CRL's Issuing Distribution Point (IDP) field. Hope this helps. Thank you.

  Thanks Leo

  I have sent the certificates to you, if you could have a peek?

  What I can see is that the CDP and IDP are the same, except that one is plain and the other one is encoded:

  CDP URL: http://some.host.com/pki/company Enterprise CA1 - G1.crl
  IDP URL: http://some.host.com/pki/company%20Enterprise%20CA1%20-%20G1.crl

  Could this be a problem? Is this by design?

  I want to stress that those names are generated by a Windows Enterprise CA, and that the Windows CA sets these URL's. The CDP extension is configured to publish the CRL as:

  http://some.host.com/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

  
  the CA Name happens to have spaces.

  Thanks
  Michel

  ---

  www.quadrotech-it.com - All your Enterprise Vault / Exchange / PST Migration Tools

  
  
  

  • Edited by MichelZ Wednesday, May 7, 2014 6:31 AM

  Wednesday, May 7, 2014 6:04 AM
• 

  

  0

  Sign in to vote

  Thanks Leo

  I have sent the certificates to you, if you could have a peek?

  What I can see is that the CDP and IDP are the same, except that one is plain and the other one is encoded:

  CDP URL: http://some.host.com/pki/company Enterprise CA1 - G1.crl
  IDP URL: http://some.host.com/pki/company%20Enterprise%20CA1%20-%20G1.crl

  Could this be a problem? Is this by design?

  I want to stress that those names are generated by a Windows Enterprise CA, and that the Windows CA sets these URL's. The CDP extension is configured to publish the CRL as:

  http://some.host.com/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

  
  the CA Name happens to have spaces.

  Thanks
  Michel
  

  Michel, the names have to precisely match, so both have to be using whitespace or both using %20. Certificate generation is outside of my expertise, so I can't tell where the problem was. As an example, Microsoft leaf cert at https://sls.update.microsoft.com has %20 in its CDP (note the text in parenthesis):

  [1]CRL Distribution Point
       Distribution Point Name:
            Full Name:
                 URL=http://www.microsoft.com/pkiops/crl/Microsoft Update Secure Server CA 2.1.crl (http://www.microsoft.com/pkiops/crl/Microsoft%20Update%20Secure%20Server%20CA%202.1.crl)

  Should you have further questions on this, you will be better assisted in CAPI/security related forum by people who are much more knowledgeable in certificates than me :)

  Thank you.

  Wednesday, May 7, 2014 8:08 PM
• 

  

  0

  Sign in to vote

  Thanks Leo. I have re-issued the WSUS Certificate, and it now magically features BOTH url's in it's CRL, a normal and an escaped one, and the WSUS error is GONE.

  ---

  www.quadrotech-it.com - All your Enterprise Vault / Exchange / PST Migration Tools

  Thursday, May 8, 2014 3:48 PM
• 

  

  0

  Sign in to vote

  I could have sworn I updated this a few days ago, but I don't see my post, so I'll try again...

  I upgraded the WSUS server in an affected test network and the problem has stopped.  I simply migrated it from a Windows 2012 server to a new Windows 2012 R2 server.  I migrated the DB and kept the same name, so the only real difference is the OS and a new web cert (from the same CA). 

  The bad news is that I can't send you the diagnostics because I no longer have the problem!

  Tuesday, May 13, 2014 8:00 PM
• 

  

  0

  Sign in to vote

  Windows 8.1 Store and Windows Update client improvements: May 13, 2014:
  http://support.microsoft.com/kb/2956575
  

  About the new features that are enabled for the Windows Update

  • Windows Update integrates with SleepStudy
          (http://msdn.microsoft.com/en-us/library/windows/hardware/dn495346(v=vs.85).aspx)    
    to provide improved diagnostic information.
  • Improvements to performance, resiliency, and support for authenticated proxies in Windows Update.
  
  

  Which may be fixed in this month's update?

  ---

  Unfortunately TechNet subscriptions aren&#39;t coming back, sorry folks :-(

  Tuesday, May 13, 2014 9:01 PM