Answered by:
KB2919355 (8.1. update 1) breaks WSUS clients

Question
-
I have a Server2012R2 hyper-v test system I use to spin up dev VM's. I decided to build a new template VM with KB2919355 (81. Update 1) installed. I patch using a WSUS instance on a physical server. All went well until I installed Update 1. When I installed the update I lost WSUS connectivity.
Any attempt to check gets an immediate failure with code 80072f8f. This usually indicates that there is a time problem between the machines. I have verified that the times are not adrift and synchronised both client and server with a geophrapically close publicly available ntp server. The times on the machines do not differ in any meaningful way. I believe that KB2919355 introduces this problem.
I built another template VM to test this issue and I have proven that contact with the WSUS server fails immediately after the installation of KB2919355 and is restored by uninstallation.
Can anyone confirm this is a bug? Can you suggest a way to resolve it without uninstalling the update? If this can be confirmed and not resolved can someone tell me how best to report this to get it investigated. I can provide any additional information you need, just ask.
The log of the failure follows for completeness but I don't believe it is very useful.
2014-04-06 13:26:51:010 716 818 Misc =========== Logging initialized (build: 7.9.9600.17031, tz: +0100) =========== 2014-04-06 13:26:51:010 716 818 Misc = Process: C:\Windows\system32\svchost.exe 2014-04-06 13:26:51:010 716 818 Misc = Module: c:\windows\system32\wuaueng.dll 2014-04-06 13:26:51:010 716 818 Service ************* 2014-04-06 13:26:51:010 716 818 Service ** START ** Service: Service startup 2014-04-06 13:26:51:010 716 818 Service ********* 2014-04-06 13:26:51:025 716 818 Agent * WU client version 7.9.9600.17031 2014-04-06 13:26:51:025 716 818 Agent * Base directory: C:\Windows\SoftwareDistribution 2014-04-06 13:26:51:025 716 818 Agent * Access type: No proxy 2014-04-06 13:26:51:025 716 818 Service UpdateNetworkState Ipv6, cNetworkInterfaces = 3. 2014-04-06 13:26:51:025 716 818 Service UpdateNetworkState Ipv4, cNetworkInterfaces = 1. 2014-04-06 13:26:51:025 716 818 Agent * Network state: Connected 2014-04-06 13:26:51:041 716 818 Service UpdateNetworkState Ipv6, cNetworkInterfaces = 3. 2014-04-06 13:26:51:041 716 818 Service UpdateNetworkState Ipv4, cNetworkInterfaces = 1. 2014-04-06 13:26:51:103 716 818 Agent *********** Agent: Initializing global settings cache *********** 2014-04-06 13:26:51:103 716 818 Agent * Endpoint Provider: 00000000-0000-0000-0000-000000000000 2014-04-06 13:26:51:103 716 818 Agent * WSUS server: https://server2:8531 2014-04-06 13:26:51:103 716 818 Agent * WSUS status server: https://server2:8531 2014-04-06 13:26:51:103 716 818 Agent * Target group: (Unassigned Computers) 2014-04-06 13:26:51:103 716 818 Agent * Windows Update access disabled: No 2014-04-06 13:26:51:119 716 818 Misc WARNING: Network Cost is assumed to be not supported as something failed with trying to get handles to wcmapi.dll 2014-04-06 13:26:51:119 716 818 WuTask WuTaskManager delay initialize completed successfully.. 2014-04-06 13:26:51:135 716 818 Report WARNING: CSerializationHelper:: InitSerialize failed : 0x80070002 2014-04-06 13:26:51:135 716 818 Report CWERReporter::Init succeeded 2014-04-06 13:26:51:150 716 818 Agent *********** Agent: Initializing Windows Update Agent *********** 2014-04-06 13:26:51:150 716 818 DnldMgr Download manager restoring 0 downloads 2014-04-06 13:26:51:150 716 818 Agent Attempt 1 to obtain post-reboot results for event with cookie 30364035_4059980412. 2014-04-06 13:26:51:541 716 818 Handler Post-reboot status for session 30364035_4059980412: 0x00000000. 2014-04-06 13:26:51:682 716 818 Report *********** Report: Initializing static reporting data *********** 2014-04-06 13:26:51:682 716 818 Report * OS Version = 6.3.9600.0.0.197008 2014-04-06 13:26:51:682 716 818 Report * OS Product Type = 0x00000008 2014-04-06 13:26:51:697 716 818 Report * Computer Brand = Microsoft Corporation 2014-04-06 13:26:51:697 716 818 Report * Computer Model = Virtual Machine 2014-04-06 13:26:51:697 716 818 Report * Platform Role = 1 2014-04-06 13:26:51:697 716 818 Report * AlwaysOn/AlwaysConnected (AOAC) = 0 2014-04-06 13:26:51:697 716 818 Report * Bios Revision = Hyper-V UEFI Release v1.0 2014-04-06 13:26:51:697 716 818 Report * Bios Name = Hyper-V UEFI Release v1.0 2014-04-06 13:26:51:697 716 818 Report * Bios Release Date = 2012-11-26T00:00:00 2014-04-06 13:26:51:697 716 818 Report * Bios Sku Number = None 2014-04-06 13:26:51:697 716 818 Report * Bios Vendor = Microsoft Corporation 2014-04-06 13:26:51:697 716 818 Report * Bios Family = Virtual Machine 2014-04-06 13:26:51:697 716 818 Report * Bios Major Release = 1 2014-04-06 13:26:51:697 716 818 Report * Bios Minor Release = 0 2014-04-06 13:26:51:697 716 818 Report * Locale ID = 2057 2014-04-06 13:26:51:713 716 818 AU ########### AU: Initializing Automatic Updates ########### 2014-04-06 13:26:51:713 716 818 AU AIR Mode is disabled 2014-04-06 13:26:51:713 716 818 AU # Policy Driven Provider: https://server2:8531 2014-04-06 13:26:51:713 716 818 AU # Detection frequency: 22 2014-04-06 13:26:51:713 716 818 AU # Approval type: Pre-install notify (User preference) 2014-04-06 13:26:51:713 716 818 AU # Auto-install minor updates: No (Policy) 2014-04-06 13:26:51:713 716 818 AU WARNING: Failed to get Wu Exemption info from NLM, assuming not exempt, error = 0x80240037 2014-04-06 13:26:51:713 716 818 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:26:51:728 716 818 AU AU finished delayed initialization 2014-04-06 13:26:51:728 716 818 AU Processing post-reboot results now. 2014-04-06 13:26:51:728 716 818 AU Obtained Post reboot hr from Agent:0 2014-04-06 13:26:51:728 716 818 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:26:51:728 716 818 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:26:51:728 716 818 AU Triggering Offline detection (non-interactive) 2014-04-06 13:26:51:744 716 818 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:26:51:744 716 818 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:26:51:744 716 578 IdleTmr Incremented idle timer priority operation counter to 1 2014-04-06 13:26:51:744 1872 268 Misc =========== Logging initialized (build: 7.9.9600.17031, tz: +0100) =========== 2014-04-06 13:26:51:744 1872 268 Misc = Process: C:\Windows\Explorer.EXE 2014-04-06 13:26:51:744 1872 268 Misc = Module: C:\Windows\system32\wucltux.dll 2014-04-06 13:26:51:744 1872 268 CltUI FATAL: CNetworkCostChangeHandler::RegisterForCostChangeNotifications: CoCreateInstance failed with error 80004002 2014-04-06 13:26:51:744 1872 268 CltUI WARNING: RegisterNetworkCostChangeNotification: Error 80004002 2014-04-06 13:26:51:744 716 818 AU ############# 2014-04-06 13:26:51:744 716 818 AU ## START ## AU: Search for updates 2014-04-06 13:26:51:744 716 818 AU ######### 2014-04-06 13:26:51:744 716 7e8 DnldMgr Asking handlers to reconcile their sandboxes 2014-04-06 13:26:51:744 716 818 IdleTmr WU operation (CSearchCall::Init ID 1) started; operation # 11; does not use network; is at background priority 2014-04-06 13:26:51:744 716 818 IdleTmr Incremented PDC RefCount for System to 1 2014-04-06 13:26:51:744 716 818 Agent *** START *** Queueing Finding updates [CallerId = AutomaticUpdates Id = 1] 2014-04-06 13:26:51:744 716 818 AU <<## SUBMITTED ## AU: Search for updates [CallId = {72AE3FB8-B8D7-41DD-8095-747A40D4D29C} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}] 2014-04-06 13:26:51:744 716 998 Agent *** END *** Queueing Finding updates [CallerId = AutomaticUpdates Id = 1] 2014-04-06 13:26:51:744 716 998 Agent ************* 2014-04-06 13:26:51:744 716 998 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates Id = 1] 2014-04-06 13:26:51:744 716 998 Agent ********* 2014-04-06 13:26:51:744 716 998 Agent * Online = No; Ignore download priority = No 2014-04-06 13:26:51:744 716 998 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-06 13:26:51:744 716 998 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed 2014-04-06 13:26:51:744 716 998 Agent * Search Scope = {Machine & All Users} 2014-04-06 13:26:51:744 716 998 Agent * Caller SID for Applicability: S-1-5-18 2014-04-06 13:26:53:775 716 62c AU Triggering AU detection through DetectNow API 2014-04-06 13:26:53:775 716 62c AU Will do the detection after current detection completes 2014-04-06 13:26:55:838 716 998 Agent * Found 0 updates and 70 categories in search; evaluated appl. rules of 300 out of 594 deployed entities 2014-04-06 13:26:55:853 716 998 Agent ********* 2014-04-06 13:26:55:853 716 998 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates Id = 1] 2014-04-06 13:26:55:853 716 998 Agent ************* 2014-04-06 13:26:55:853 716 998 IdleTmr WU operation (CSearchCall::Init ID 1, operation # 11) stopped; does not use network; is at background priority 2014-04-06 13:26:55:853 716 998 IdleTmr Decremented PDC RefCount for System to 0 2014-04-06 13:26:55:853 716 7fc AU >>## RESUMED ## AU: Search for updates [CallId = {72AE3FB8-B8D7-41DD-8095-747A40D4D29C} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}] 2014-04-06 13:26:55:853 716 7fc AU # 0 updates detected 2014-04-06 13:26:55:853 716 7fc AU ######### 2014-04-06 13:26:55:853 716 7fc AU ## END ## AU: Search for updates [CallId = {72AE3FB8-B8D7-41DD-8095-747A40D4D29C} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}] 2014-04-06 13:26:55:853 716 7fc AU ############# 2014-04-06 13:26:55:853 716 7fc AU All AU searches complete. 2014-04-06 13:26:55:853 716 7fc AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:26:55:853 716 7fc AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:26:55:869 716 818 AU ############# 2014-04-06 13:26:55:869 716 818 AU ## START ## AU: Search for updates 2014-04-06 13:26:55:869 716 818 AU ######### 2014-04-06 13:26:55:869 716 818 IdleTmr WU operation (CSearchCall::Init ID 2) started; operation # 21; does use network; is not at background priority 2014-04-06 13:26:55:869 716 818 IdleTmr Incremented PDC RefCount for Network to 1 2014-04-06 13:26:55:869 716 818 IdleTmr Incremented idle timer priority operation counter to 2 2014-04-06 13:26:55:869 716 818 Agent *** START *** Queueing Finding updates [CallerId = AutomaticUpdates Id = 2] 2014-04-06 13:26:55:869 716 818 AU <<## SUBMITTED ## AU: Search for updates [CallId = {30796857-9E66-4E16-BEF6-71729D4A5910} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}] 2014-04-06 13:26:55:869 716 998 Agent *** END *** Queueing Finding updates [CallerId = AutomaticUpdates Id = 2] 2014-04-06 13:26:55:869 716 998 Agent ************* 2014-04-06 13:26:55:869 716 998 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates Id = 2] 2014-04-06 13:26:55:869 716 998 Agent ********* 2014-04-06 13:26:55:869 716 998 Agent * Online = Yes; Ignore download priority = No 2014-04-06 13:26:55:869 716 998 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-06 13:26:55:869 716 998 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed 2014-04-06 13:26:55:869 716 998 Agent * Search Scope = {Machine & All Users} 2014-04-06 13:26:55:869 716 998 Agent * Caller SID for Applicability: S-1-5-18 2014-04-06 13:26:55:869 716 998 EP Got WSUS Client/Server URL: "https://server2:8531/ClientWebService/client.asmx" 2014-04-06 13:26:55:869 716 7e8 Report REPORT EVENT: {F868CFA9-FA42-4825-BE0E-BEBE0D7C35D2} 2014-04-06 13:26:51:713+0100 1 183 [AGENT_INSTALLING_SUCCEEDED] 101 {ACBE97D7-83F2-410D-97CF-5A63D58D6923} 501 0 wusa Success Content Install Installation Successful: Windows successfully installed the following update: Update for Windows (KB2919355) 2014-04-06 13:26:55:869 716 7e8 Report WARNING: Failed to get service object: 80248014 2014-04-06 13:26:55:869 716 7e8 Report WARNING: Failed to get service object: 80248014 2014-04-06 13:26:55:869 716 7e8 Report CWERReporter finishing event handling. (00000000) 2014-04-06 13:26:55:885 716 998 Setup Checking for agent SelfUpdate 2014-04-06 13:26:55:885 716 998 Setup Client version: Core: 7.9.9600.17031 Aux: 7.9.9600.17031 2014-04-06 13:26:55:885 716 998 EP Got WSUS SelfUpdate URL: "https://server2:8531/selfupdate" 2014-04-06 13:26:56:322 716 998 Misc WARNING: Send failed with hr = 80072f8f. 2014-04-06 13:26:56:322 716 998 Misc WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None> 2014-04-06 13:26:56:322 716 998 Misc WARNING: Send request failed, hr:0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <https://server2:8531/selfupdate/wuident.cab>. error 0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: Send failed with hr = 80072f8f. 2014-04-06 13:26:56:322 716 998 Misc WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None> 2014-04-06 13:26:56:322 716 998 Misc WARNING: Send request failed, hr:0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <https://server2:8531/selfupdate/wuident.cab>. error 0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f 2014-04-06 13:26:56:322 716 998 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f 2014-04-06 13:26:56:338 716 998 Misc WARNING: Send failed with hr = 80072f8f. 2014-04-06 13:26:56:353 716 998 Misc WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None> 2014-04-06 13:26:56:353 716 998 Misc WARNING: Send request failed, hr:0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <https://server2:8531/selfupdate/wuident.cab>. error 0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: Send failed with hr = 80072f8f. 2014-04-06 13:26:56:353 716 998 Misc WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None> 2014-04-06 13:26:56:353 716 998 Misc WARNING: Send request failed, hr:0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <https://server2:8531/selfupdate/wuident.cab>. error 0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f8f 2014-04-06 13:26:56:353 716 998 Misc WARNING: DownloadFileInternal failed for https://server2:8531/selfupdate/wuident.cab: error 0x80072f8f 2014-04-06 13:26:56:353 716 998 Setup FATAL: DownloadCab failed, err = 0x80072F8F 2014-04-06 13:26:56:353 716 998 Setup WARNING: SelfUpdate check failed to download package information, err = 0x80072F8F 2014-04-06 13:26:56:353 716 998 Setup FATAL: SelfUpdate check failed, err = 0x80072F8F 2014-04-06 13:26:56:353 716 998 Agent * WARNING: Skipping scan, self-update check returned 0x80072F8F 2014-04-06 13:26:56:369 716 998 Agent * WARNING: Exit code = 0x80072F8F 2014-04-06 13:26:56:369 716 998 Agent ********* 2014-04-06 13:26:56:369 716 998 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates Id = 2] 2014-04-06 13:26:56:369 716 998 Agent ************* 2014-04-06 13:26:56:369 716 998 Agent WARNING: WU client failed Searching for update with error 0x80072f8f 2014-04-06 13:26:56:369 716 998 IdleTmr WU operation (CSearchCall::Init ID 2, operation # 21) stopped; does use network; is not at background priority 2014-04-06 13:26:56:369 716 998 IdleTmr Decremented PDC RefCount for Network to 0 2014-04-06 13:26:56:369 716 998 IdleTmr Decremented idle timer priority operation counter to 1 2014-04-06 13:26:56:369 716 7fc AU >>## RESUMED ## AU: Search for updates [CallId = {30796857-9E66-4E16-BEF6-71729D4A5910} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}] 2014-04-06 13:26:56:369 716 7fc AU # WARNING: Search callback failed, result = 0x80072F8F 2014-04-06 13:26:56:369 716 7fc AU ######### 2014-04-06 13:26:56:369 716 7fc AU ## END ## AU: Search for updates [CallId = {30796857-9E66-4E16-BEF6-71729D4A5910} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}] 2014-04-06 13:26:56:369 716 7fc AU ############# 2014-04-06 13:26:56:369 716 7fc AU All AU searches complete. 2014-04-06 13:26:56:369 716 7fc AU # WARNING: Failed to find updates with error code 80072f8f 2014-04-06 13:26:56:369 716 7fc AU AU setting next detection timeout to 2014-04-06 17:26:56 2014-04-06 13:26:56:369 716 7fc AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:26:56:369 716 7fc AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2014-04-06 13:27:01:357 716 7e8 Report REPORT EVENT: {1C156472-29A0-41E3-8686-11F82CA313B8} 2014-04-06 13:26:56:353+0100 1 148 [AGENT_DETECTION_FAILED] 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 1 80072f8f SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x80072f8f. 2014-04-06 13:27:01:373 716 7e8 Report CWERReporter::HandleEvents - WER report upload completed with status 0x8 2014-04-06 13:27:01:373 716 7e8 Report WER Report sent: 7.9.9600.17031 0x80072f8f(0) D67661EB-2423-451D-BF5D-13199E37DF28 Scan 101 Managed 2014-04-06 13:27:01:373 716 7e8 Report CWERReporter finishing event handling. (00000000) 2014-04-06 13:27:35:305 716 aec IdleTmr Decremented idle timer priority operation counter to 0 2014-04-06 13:31:33:546 716 818 AU ########### AU: Uninitializing Automatic Updates ########### 2014-04-06 13:31:33:560 716 818 WuTask Uninit WU Task Manager 2014-04-06 13:31:33:794 716 818 Service ********* 2014-04-06 13:31:33:794 716 818 Service ** END ** Service: Service exit [Exit code = 0x240001] 2014-04-06 13:31:33:794 716 818 Service *************
Sunday, April 6, 2014 1:00 PM
Answers
-
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 -
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
All replies
-
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 -
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 -
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 -
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 -
For us to better assist you, can you please specify:
- Which version of WSUS do you have installed and on which version of Windows Server?
- Please list any QFE (KB#s) that you have installed on the WSUS server.
Thanks,
BenMonday, April 7, 2014 4:30 PM -
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 -
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 -
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 -
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 -
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 -
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 ClientMonday, April 7, 2014 6:08 PM -
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 -
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 -
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 -
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.
Monday, April 7, 2014 7:25 PM -
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 ServerTuesday, April 8, 2014 6:43 AM -
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 -
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 -
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 -
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
-
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
-
Windows 8.1 Update prevents interaction with WSUS 3.2 over SSL
- WSUSProduct Team Blog - Site Home - TechNet Blogs:
*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 timeUnfortunately TechNet subscriptions aren't coming back, sorry folks :-(
Tuesday, April 8, 2014 7:41 PM -
You can also just turn on TLS 1.2 to be extra sure.Tuesday, April 8, 2014 9:05 PM
-
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 -
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 -
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
-
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 -
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
-
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 -
FYI
Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(
Thursday, April 17, 2014 6:30 AM -
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 -
Hello,
I tested against the following Proxies:
Sophos UTM220 V9.109
Trend Micro IWSVA V5.6
Websense V7.7I 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 -
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 -
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 -
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
-
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 -
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 -
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 -
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 -
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 -
Hi CFS3rd, would you please share windowsupdate.log? Thank you.Friday, April 25, 2014 5:24 PM
-
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 -
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 -
Hello Leo Lie,
here are my answers:
1. Is the proxy server the same for both working and non-working OU?
-> Yes3. 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 -
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":
Monday, April 28, 2014 4:00 AM -
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":
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 stop5. 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 -
Hello Leo Lie,
here are my answers:
1. Is the proxy server the same for both working and non-working OU?
-> Yes3. 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 stop5. 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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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=ieYou 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 -
Diagnostic information sent.
Thanks.
Friday, May 2, 2014 2:39 AM -
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 -
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 -
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.cabI 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 -
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 /flushdns1. Start network tracing by running this command as admin:
netsh trace start scenario=InternetClient2. 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 stop5. 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 -
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 -
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 -
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.crlCould 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 -
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.crlCould 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 -
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 -
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 -
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't coming back, sorry folks :-(
Tuesday, May 13, 2014 9:01 PM - Windows Update integrates with
SleepStudy