locked
Problems with WSUS over VPN RRS feed

  • Question

  • A while back we started having trouble with our WSUS server communicating with our laptops over our VPN. We've been just running updates manually, but it's become a priority to find out what the issue is so that we can resume using it to deploy other software packages.

    We're getting the following in our WindowsUpdate.log:

    2014-08-21	10:40:50:083	1168	63c	AU	Triggering AU detection through DetectNow API
    2014-08-21	10:40:50:083	1168	63c	AU	Triggering Online detection (interactive)
    2014-08-21	10:40:50:083	1168	a80	AU	#############
    2014-08-21	10:40:50:083	1168	a80	AU	## START ##  AU: Search for updates
    2014-08-21	10:40:50:083	1168	a80	AU	#########
    2014-08-21	10:40:50:083	1168	a80	AU	<<## SUBMITTED ## AU: Search for updates [CallId = {414E9C34-F810-46D5-9D6B-01001BCE24FB}]
    2014-08-21	10:40:58:211	1168	cf4	Misc	WARNING: Send failed with hr = 80072ee2.
    2014-08-21	10:40:58:211	1168	cf4	Misc	WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2014-08-21	10:40:58:211	1168	cf4	PT	  + Last proxy send request failed with hr = 0x80072EE2, HTTP status code = 0
    2014-08-21	10:40:58:211	1168	cf4	PT	  + Caller provided credentials = No
    2014-08-21	10:40:58:211	1168	cf4	PT	  + Impersonate flags = 0
    2014-08-21	10:40:58:211	1168	cf4	PT	  + Possible authorization schemes used = 
    2014-08-21	10:40:58:211	1168	cf4	PT	WARNING: SyncUpdates failure, error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status code = 200
    2014-08-21	10:40:58:211	1168	cf4	PT	WARNING: PTError: 0x80072ee2
    2014-08-21	10:40:58:211	1168	cf4	PT	WARNING: SyncUpdates_WithRecovery failed.: 0x80072ee2
    2014-08-21	10:40:58:211	1168	cf4	PT	WARNING: Sync of Updates: 0x80072ee2
    2014-08-21	10:40:58:211	1168	cf4	PT	WARNING: SyncServerUpdatesInternal failed: 0x80072ee2
    2014-08-21	10:40:58:211	1168	cf4	Agent	  * WARNING: Failed to synchronize, error = 0x80072EE2
    2014-08-21	10:40:58:211	1168	cf4	Agent	  * WARNING: Exit code = 0x80072EE2
    2014-08-21	10:40:58:211	1168	cf4	Agent	*********
    2014-08-21	10:40:58:211	1168	cf4	Agent	**  END  **  Agent: Finding updates [CallerId = ]
    2014-08-21	10:40:58:211	1168	cf4	Agent	*************
    2014-08-21	10:40:58:211	1168	cf4	Agent	WARNING: WU client failed Searching for update with error 0x80072ee2
    2014-08-21	10:40:58:226	1168	cf4	Agent	*************
    2014-08-21	10:40:58:226	1168	cf4	Agent	** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2014-08-21	10:40:58:226	1168	cf4	Agent	*********
    2014-08-21	10:40:58:226	1168	cf4	Agent	  * Online = Yes; Ignore download priority = No
    2014-08-21	10:40:58:226	1168	cf4	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-08-21	10:40:58:226	1168	cf4	Agent	  * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2014-08-21	10:40:58:226	1168	cf4	Agent	  * Search Scope = {Machine}
    2014-08-21	10:40:58:226	1168	cf4	Setup	Checking for agent SelfUpdate
    2014-08-21	10:40:58:226	1168	cf4	Setup	Client version: Core: 7.6.7600.256  Aux: 7.6.7600.256
    2014-08-21	10:40:58:226	 584	db4	COMAPI	>>--  RESUMED  -- COMAPI: Search [ClientId = <NULL>]
    2014-08-21	10:40:58:226	 584	db4	COMAPI	  - Updates found = 0
    2014-08-21	10:40:58:226	 584	db4	COMAPI	  - WARNING: Exit code = 0x00000000, Result code = 0x80072EE2
    2014-08-21	10:40:58:226	 584	db4	COMAPI	---------
    2014-08-21	10:40:58:226	 584	db4	COMAPI	--  END  --  COMAPI: Search [ClientId = <NULL>]
    2014-08-21	10:40:58:226	 584	db4	COMAPI	-------------
    2014-08-21	10:40:58:226	 584	84c	COMAPI	WARNING: Operation failed due to earlier error, hr=80072EE2
    2014-08-21	10:40:58:226	 584	84c	COMAPI	FATAL: Unable to complete asynchronous search. (hr=80072EE2)
    2014-08-21	10:40:58:258	1168	cf4	Misc	Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2014-08-21	10:40:58:273	1168	cf4	Misc	 Microsoft signed: Yes
    2014-08-21	10:41:19:333	1168	cf4	Misc	WARNING: Send failed with hr = 80072ee2.
    2014-08-21	10:41:19:333	1168	cf4	Misc	WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2014-08-21	10:41:19:333	1168	cf4	Misc	WARNING: WinHttp: SendRequestUsingProxy failed for <http://{servername}/selfupdate/wuident.cab>. error 0x80072ee2
    2014-08-21	10:41:19:333	1168	cf4	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
    2014-08-21	10:41:19:333	1168	cf4	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
    2014-08-21	10:41:19:333	1168	cf4	Misc	WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
    2014-08-21	10:41:40:362	1168	cf4	Misc	WARNING: Send failed with hr = 80072ee2.
    2014-08-21	10:41:40:362	1168	cf4	Misc	WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2014-08-21	10:41:40:362	1168	cf4	Misc	WARNING: WinHttp: SendRequestUsingProxy failed for <http://{servername}/selfupdate/wuident.cab>. error 0x80072ee2
    2014-08-21	10:41:40:362	1168	cf4	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
    2014-08-21	10:41:40:362	1168	cf4	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
    2014-08-21	10:41:40:362	1168	cf4	Misc	WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
    2014-08-21	10:42:01:391	1168	cf4	Misc	WARNING: Send failed with hr = 80072ee2.
    2014-08-21	10:42:01:391	1168	cf4	Misc	WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2014-08-21	10:42:01:391	1168	cf4	Misc	WARNING: WinHttp: SendRequestUsingProxy failed for <http://{servername}/selfupdate/wuident.cab>. error 0x80072ee2
    2014-08-21	10:42:01:391	1168	cf4	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
    2014-08-21	10:42:01:391	1168	cf4	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
    2014-08-21	10:42:01:391	1168	cf4	Misc	WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
    2014-08-21	10:42:22:435	1168	cf4	Misc	WARNING: Send failed with hr = 80072ee2.
    2014-08-21	10:42:22:435	1168	cf4	Misc	WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2014-08-21	10:42:22:435	1168	cf4	Misc	WARNING: WinHttp: SendRequestUsingProxy failed for <http://{servername}/selfupdate/wuident.cab>. error 0x80072ee2
    2014-08-21	10:42:22:435	1168	cf4	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
    2014-08-21	10:42:22:435	1168	cf4	Misc	WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
    2014-08-21	10:42:22:435	1168	cf4	Misc	WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
    2014-08-21	10:42:22:435	1168	cf4	Misc	WARNING: DownloadFileInternal failed for http://{servername}/selfupdate/wuident.cab: error 0x80072ee2
    2014-08-21	10:42:22:435	1168	cf4	Setup	WARNING: SelfUpdate check failed to download package information, error = 0x80072EE2
    2014-08-21	10:42:22:435	1168	cf4	Setup	FATAL: SelfUpdate check failed, err = 0x80072EE2
    2014-08-21	10:42:22:435	1168	cf4	Agent	  * WARNING: Skipping scan, self-update check returned 0x80072EE2
    2014-08-21	10:42:22:435	1168	cf4	Agent	  * WARNING: Exit code = 0x80072EE2
    

    Here's what the client diagnostic tool returns:

    WSUS Client Diagnostics Tool
    
    Checking Machine State
            Checking for admin rights to run tool . . . . . . . . . PASS
            Automatic Updates Service is running. . . . . . . . . . PASS
            Background Intelligent Transfer Service is not running. PASS
            Wuaueng.dll version 7.6.7600.256. . . . . . . . . . . . PASS
                    This version is WSUS 2.0
    
    Checking AU Settings
            AU Option is 4: Scheduled Install . . . . . . . . . . . PASS
                    Option is from Policy settings
    
    Checking Proxy Configuration
            Checking for winhttp local machine Proxy settings . . . PASS
                    Winhttp local machine access type
                            <Direct Connection>
                    Winhttp local machine Proxy. . . . . . . . . .  NONE
                    Winhttp local machine ProxyBypass. . . . . . .  NONE
            Checking User IE Proxy settings . . . . . . . . . . . . PASS
                    User IE Proxy. . . . . . . . . . . . . . . . .  NONE
                    User IE ProxyByPass. . . . . . . . . . . . . .  NONE
                    User IE AutoConfig URL Proxy . . . . . . . . .  NONE
                    User IE AutoDetect
                    AutoDetect not in use
    
    Checking Connection to WSUS/SUS Server
                    WUServer = http://{servername}
                    WUStatusServer = http://{servername}
            UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
            Connection to server. . . . . . . . . . . . . . . . . . PASS
            SelfUpdate folder is present. . . . . . . . . . . . . . PASS
    
    Press Enter to Complete

    Both of the above were run without any firewall at all. For some reason it appears as though (in the log anyway) it's trying to use a proxy. (when it shouldn't)

    Updates work perfectly when plugged into our network, and while they're on the VPN they have access to all network resources. (mapped drives, etc)

    Any help would be greatly appreciated, as I'm afraid this one has me stumped.

    Thursday, August 21, 2014 3:59 PM

All replies

  • A while back we started having trouble with our WSUS server communicating with our laptops over our VPN.

    First note here that may significantly assist in your diagnostics... the WSUS Server does NOT communicate with clients.. the *CLIENTS* communicate with the WSUS Server. So, it's not about the pathway from server-to-client, but rather from client-TO-server.

    Ergo.. why can the clients not find the WSUS server when connected via VPN?

    AU <<## SUBMITTED ## AU: Search for updates [CallId = {414E9C34-F810-46D5-9D6B-01001BCE24FB}]

    I have no idea what/where this call to the WUA is coming from, but it's failing with a TIMEOUT error. My assumption, all other things considered, is that this is NOT a call to the assigned WSUS server. At a minimum, it's not a standard WUA detection for updates from a WSUS server.

    Checking Connection to WSUS/SUS Server

    WUServer = http://{servername}

    WUStatusServer = http://{servername}

    UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS

    Connection to server. . . . . . . . . . . . . . . . . . PASS

    SelfUpdate folder is present. . . . . . . . . . . . . . PASS

    Presumably the WSUS server communication is working perfectly, but I'll have to offer that as an assumption ONLY since I don't actually know what the client is talking to since you've masked that critical information from your query. I'm also assuming this CDT output is from a client actually connected to the VPN.

    ALSO: Please do NOT post logfiles in CODE BLOCKS... it makes them impossible to read, and I HATE horizontal scrolling. Just post them as *TEXT*.

    For some reason it appears as though (in the log anyway) it's trying to use a proxy. (when it shouldn't)

    Are the clients configured to USE a proxy when they shouldn't be? SHOULD they be required to use a proxy on the VPN connection and they're not? I can't tell what OS version the client is, since the logs are not complete enough, but since it's -2014- I'm going to assume it's a Vista or later client.

    What's the output from NETSH WINHTTP SHOW PROXY?


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, August 22, 2014 1:53 AM
  • Ergo.. why can the clients not find the WSUS server when connected via VPN?

    Yes, I am aware that WSUS is a pull system, please excuse my phrasing.


    Presumably the WSUS server communication is working perfectly, but I'll have to offer that as an assumption ONLY since I don't actually know what the client is talking to since you've masked that critical information from your query. I'm also assuming this CDT output is from a client actually connected to the VPN.

    Yes, communication works perfectly (I can browse to http://{servername}/iuident.cab and download the file). The {servername} is literally just the "computer name" of our server. Would it work better to use the FQDN? It's all been set up since long before I got here and working without issue so I was under the assumption it was non-issue. All logs posted were from the same computer (seconds apart) running over our VPN.

    Are the clients configured to USE a proxy when they shouldn't be? SHOULD they be required to use a proxy on the VPN connection and they're not? I can't tell what OS version the client is, since the logs are not complete enough, but since it's -2014- I'm going to assume it's a Vista or later client. What's the output from NETSH WINHTTP SHOW PROXY?

    No, no proxy is configured, nor to my knowledge have we ever used one. No, there's no need for a proxy. The computers in question all run Windows 7.

    NETSH WINHTTP SHOW PROXY:

    Current WinHTTP proxy settings:

        Direct access (no proxy server).

    Thanks for your help!
    • Edited by bcarlock Friday, August 22, 2014 1:35 PM Gratitude.
    Friday, August 22, 2014 1:34 PM
  • AU <<## SUBMITTED ## AU: Search for updates [CallId = {414E9C34-F810-46D5-9D6B-01001BCE24FB}] I have no idea what/where this call to the WUA is coming from, but it's failing with a TIMEOUT error. My assumption, all other things considered, is that this is NOT a call to the assigned WSUS server. At a minimum, it's not a standard WUA detection for updates from a WSUS server.
    Is it possible that the line in question from the log is caused by manually clicking the "Check for Updates" in windows 7? Because that's what I did.
    Friday, August 22, 2014 2:05 PM
  • I changed the update server to be the FQDN with no result.
    Friday, August 22, 2014 4:03 PM
  • More or less at exactly the same place, but I got rid of the cookie message.

    Here's the Solarwinds diagnostic log:

    # Solarwinds® Diagnostic Tool for the WSUS Agent
    # 8/22/2014
    Machine state
      User rights:                                       User has administrator rights
      Update service status:                             Stopped
      Background Intelligent Transfer service status:    Stopped
      OS Version:                                        Windows 7 Professional  Service Pack 1
      Windows update agent version:                      7.6.7600.256 (WU Agent is OK)
    Windows Update Agent configuration settings
      Automatic Update:                                  Enabled
      Options:                                           Scheduled (Every day at  6:00 PM)
      Use WSUS Server:                                   Enabled
      Windows Update Server:                             http://wistrom
      Windows Update Status Server:                      http://wistrom
      WSUS URLs are identical:                           Identical
      WSUS URL is valid:                                 Valid URL
    WSUS Server Connectivity
      clientwebservice/client.asmx:                      OK
      simpleauthwebservice/simpleauth.asmx:              OK
      content:                                           OK
      selfupdate/iuident.cab:                            OK
      iuident.cab:                                       OK

    Friday, August 22, 2014 9:47 PM
  • Machine state
      Update service status:                             Stopped

    Well that certainly won't help. Why is the Update Service stopped?


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, August 22, 2014 10:04 PM
  • Oops, I had disabled it to clear out the software distribution folder
    Here's a post reboot scan:

    # Solarwinds® Diagnostic Tool for the WSUS Agent
    # 8/25/2014
    Machine state
      User rights:                                       User has administrator rights
      Update service status:                             Running
      Background Intelligent Transfer service status:    Stopped
      OS Version:                                        Windows 7 Professional  Service Pack 1
      Windows update agent version:                      7.6.7600.256 (WU Agent is OK)
    Windows Update Agent configuration settings
      Automatic Update:                                  Enabled
      Options:                                           Scheduled (Every day at  6:00 PM)
      Use WSUS Server:                                   Enabled
      Windows Update Server:                             http://wistrom
      Windows Update Status Server:                      http://wistrom
      WSUS URLs are identical:                           Identical
      WSUS URL is valid:                                 Valid URL
    WSUS Server Connectivity
      clientwebservice/client.asmx:                      OK
      simpleauthwebservice/simpleauth.asmx:              OK
      content:                                           OK
      selfupdate/iuident.cab:                            OK
      iuident.cab:                                       OK


    Do you know if there's any way to increase the timeout?



    Monday, August 25, 2014 1:17 PM
  • # Solarwinds® Diagnostic Tool for the WSUS Agent
    # 8/25/2014
    Machine state
      Background Intelligent Transfer service status:    Stopped

    Okay. Next Question: Why is the Background Intelligent Transfer Service stopped on a workstation operating system?

    Do you know if there's any way to increase the timeout?

    This is not a timeout related to slow performance; it's a timeout related to a non-existent connection or a connection failure, and since it's related to VPN clients, almost certainly it has something to do with the communication through the VPN.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Steven_Lee0510 Monday, September 1, 2014 3:28 AM
    • Unmarked as answer by bcarlock Wednesday, September 3, 2014 2:00 PM
    Thursday, August 28, 2014 11:25 PM
  • Okay. Next Question: Why is the Background Intelligent Transfer Service stopped on a workstation operating system?

    Good question- I'm assuming it wasn't needed? It's set to manual startup in services. Starting it by hand didn't fix it. (I changed BITS to start automatically)

    I'm not sure how it could be a connection failure when I can navigate to the WSUS server and download the CAB files manually from the same computer literally seconds after an update check fails...



    • Edited by bcarlock Friday, August 29, 2014 1:17 PM Change in BITS startup
    Friday, August 29, 2014 1:14 PM
  • Okay. Next Question: Why is the Background Intelligent Transfer Service stopped on a workstation operating system?

    Good question- I'm assuming it wasn't needed?

    No, actually it's *required*. :-)

    I'm not sure how it could be a connection failure when I can navigate to the WSUS server and download the CAB files manually from the same computer literally seconds after an update check fails...

    Because what you can do in the browser has absolutely nothing to do with what the WUA or BITS can do because they use WinHTTP.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Steven_Lee0510 Monday, September 1, 2014 3:27 AM
    • Unmarked as answer by bcarlock Wednesday, September 3, 2014 2:00 PM
    Sunday, August 31, 2014 1:02 AM
  • No, actually it's *required*. :-)

    Sorry- I meant I was assuming the system hadn't requested that it start, since it was set to manual start up. Regardless, it's automatic now and still not working.


    Test via winhttp(powershell):

    $httprequest=[System.Net.httpwebrequest]::Create('http://wistrom/selfupdate/')
    [System.Net.ServicePointManager]::ServerCertificateValidationCallback={$true}
    $response=$httprequest.GetResponse()
    $strm=$response.GetResponseStream()
    $reader=New-Object System.IO.StreamReader($strm,[System.Text.Encoding]::UTF8)
    $reader.ReadToEnd()
    



    Windows PowerShell
    Copyright (C) 2009 Microsoft Corporation. All rights reserved.

    <html><head><title>wistrom - /selfupdate/</title></head><body><H1>wistrom - /se
    lfupdate/</H1><hr>

    <pre><A HREF="/">[To Parent Directory]</A><br><br> 8/11/2014 10:56 AM        &l
    t;dir&gt; <A HREF="/selfupdate/AU/">AU</A><br> 7/20/2012  3:11 PM        17967
    <A HREF="/selfupdate/InventoryRules.cab">InventoryRules.cab</A><br>  6/2/2012
    9:40 PM        17618 <A HREF="/selfupdate/iuident.cab">iuident.cab</A><br> 7/20
    /2012  3:11 PM        17028 <A HREF="/selfupdate/muident.cab">muident.cab</A><b
    r> 8/22/2014  3:31 PM          227 <A HREF="/selfupdate/web.config">web.config<
    /A><br> 8/11/2014 10:56 AM        &lt;dir&gt; <A HREF="/selfupdate/WSUS3/">WSUS
    3</A><br> 7/20/2012  3:11 PM        17012 <A HREF="/selfupdate/wuident.cab">wui
    dent.cab</A><br></pre><hr></body></html>

    I can have it read wuident.cab as well, but powershell seemed to have a seizure when I accessed a cab file.

    Tuesday, September 2, 2014 1:29 PM
  • Test via winhttp(powershell):

    Potentially useful, but what is **WSUS** doing (or not doing)? We know the client is configured correctly, and is communicating perfectly with the WSUS Server, so now I'm a bit challenged where it is this problem exists.

    $httprequest=[System.Net.httpwebrequest]::Create('http://wistrom/selfupdate/')
    [System.Net.ServicePointManager]::ServerCertificateValidationCallback={$true}
    $response=$httprequest.GetResponse()
    $strm=$response.GetResponseStream()
    $reader=New-Object System.IO.StreamReader($strm,[System.Text.Encoding]::UTF8)
    $reader.ReadToEnd()

    I can have it read wuident.cab as well, but powershell seemed to have a seizure when I accessed a cab file.

    WHY are you doing this?

    You've already used the Diagnostic Tool. We know the client is working perfectly, configured correctly (except for the BITS service, which is trivial), and able to communicate with the WSUS server.

    Let's regroup and see if we can better define what exactly the problem is.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, September 3, 2014 1:50 PM
  • Potentially useful, but what is **WSUS** doing (or not doing)? We know the client is configured correctly, and is communicating perfectly with the WSUS Server, so now I'm a bit challenged where it is this problem exists.

    As am I. I've tested in just about every way I can possibly think of, and everything says that it's working, but windows update still reports timeout errors.

    WHY are you doing this?

    That was the powershell script used to test and confirm that winhttp was able to communicate with the server independently from windows update.

    Here's the problem verbatim:
    None of our remote computers check in to WSUS or find updates while on VPN, despite being able to contact the server in every way they should be able to.  Instead they report timeout errors. (0x80072ee2)

    Here's what I know: Everything says it should work. It doesn't.

    Do you have any suggestions as to what to try? At this point the only thing I can think of is that latency is the issue, and that the timeout is set too short for windows update.

    Also, I noticed the problem was marked solved by mods... It's nowhere near solved and never has been. In fact, nothing has changed despite all of the tinkering and testing.



    • Edited by bcarlock Wednesday, September 3, 2014 2:21 PM
    Wednesday, September 3, 2014 2:14 PM
  • As am I. I've tested in just about every way I can possibly think of, and everything says that it's working, but windows update still reports timeout errors.

    So let's quit throwing mud at the wall and use an educated, logical process to this situation.

    That was the powershell script used to test and confirm that winhttp was able to communicate with the server independently from windows update.

    And totally irrelevant. We already know that the WUA can communicate with the WSUS server, the Diagnostic Tool told us so!

    None of our remote computers check in to WSUS or find updates while on VPN, despite being able to contact the server in every way they should be able to.

    Yeah. I recall reading this in the original post. So post a WindowsUpdate.log segment with a COMPLETE detection event (including reporting) where the failure occurs while connected via the VPN. (Oh.. and please do NOT post it as a Code Segment.. just post it as plaintext.)

    Use the following process:

    1. Record the system time of the client.
    2. REBOOT the client.
    3. Connect to the VPN.
    4. Run the command WUAUCLT /RESETAUTHORIZATION /DETECTNOW from a Command Prompt.
    5. Wait THIRTY minutes.
    6. Copy the entries from the WindowsUpdate.log starting at the time recorded in Step #1 and post into a reply to this message as message text (no code segment)

    While the detection event is running in the background, also do this:

    Run NSLOOKUP <WSUSServerName> from a Command Prompt and post the results.

    Run ROUTE PRINT from a Command Prompt and post the results.

    Also, I noticed the problem was marked solved by mods...

    Yeah, this is a totally separate problem caused by contractors who can't read, or ostensibly understand English. MVPs have been griping about this problem for over a year. Apparently nobody's going to do anything about it. <sigh></sigh>


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, September 5, 2014 2:42 AM
  • While collecting logs I figured out what the problem was/fixed it. I would like to try it on a couple of other clients, but the problem was the IPV6 protocol. I noticed that nslookup was using it and unable to find our WSUS server, so I disabled it and everything started working.

    Our VPN is an oldish SSL VPN and apparently doesn't capture traffic over anything other than IPV4.

    Update:
    It's only working on my test machine. I'm working on figuring out the differences in configuration. 

    • Edited by bcarlock Friday, September 5, 2014 5:07 PM Update
    Friday, September 5, 2014 3:18 PM