locked
WSUS Keeps Crashing: Error Connection Error RRS feed

  • Question

  • Every few hours my WSUS keeps crashing. WSUS is installed alongside SCCM 2012 on server 2012 R2. It is using a database on a separate SQL server and has the WSUS data on another server.   I have IIS set to run as connected user so endpoints will get and run updates but the WSUS services do not seem to stay up long enough for many clients to get updates on their own.

    Here is the error I copied to the clipboard:

    The WSUS administration console was unable to connect to the WSUS Server via the remote API.

    Verify that the Update Services service, IIS and SQL are running on the server. If the problem persists, try restarting IIS, SQL, and the Update Services Service.

    The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists,

    Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.


    System.IO.IOException -- The handshake failed due to an unexpected packet format.

    Source
    System

    Stack Trace:
       at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
       at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
       at System.Net.ConnectStream.WriteHeaders(Boolean async)
    ** this exception was nested inside of the following exception **


    System.Net.WebException -- The underlying connection was closed: An unexpected error occurred on a send.

    Source
    Microsoft.UpdateServices.Administration

    Stack Trace:
       at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)
       at Microsoft.UpdateServices.UI.AdminApiAccess.AdminApiTools.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServer()
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.get_ServerTools()

    I am at a loss to what to begin checking to be honest.  I have gone through permissions on all the servers involved and I am pretty positive that they are adequate for WSUS to operate.   Please help point me in the right direction.   If I reboot the SCCM server I can access WSUS through the MMC for a short while up to a few hours and then it seems to crash again.

    Monday, January 11, 2016 11:51 PM

Answers

  • Turns out it was a performance issue. I forgot to come back and say I solved it by increasing the memory allocated in IIS for WSUS. I don't have the exact details but the box running this has 16GB of ram allocated, 4 Xeon CPU Cores and 2 Gig NICs teamed for throughput.
    Thursday, February 4, 2016 1:35 AM
  • I agree, you don't *need* to use SSL, it was just a thought that *may* be using SSL.. :)

    I found these after a bit more searching of the web:

    http://www.wsus.info/index.php?showtopic=13966

    https://technet.microsoft.com/en-us/library/cc708630(v=ws.10).aspx

    But, let's get back to your implementation scenario..

    This WSUS is configured as a SUP in your ConfigMgr hierarchy?
    Or, is this WSUS acting as an upstream server (it sync's to MSFT) and the ConfigMgr SUP is downstream from this WSUS box?

    I'm thinking that if this box is configured as a SUP, then you should expect ConfigMgr to be poking at this box around hourly (because that's what ConfigMgr does to WSUS). If so, is ConfigMgr setup for SUP settings that it's trying to re-assert periodically, and those settings aren't correct? (i.e. is it breaking things by asserting an incorrect config?)

    There are several ConfigMgr logs relating to WSUS interaction which you will find.

    There are also WSUS logs (c:\program files\update services\logs) worth looking into.


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, January 12, 2016 3:07 AM

All replies

  • I searched for this: https://www.bing.com/search?q=System.IO.IOException+--+The+handshake+failed+due+to+an+unexpected+packet+format&FORM=WNSIPR

    And I got these likely-lads:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/35d0d53a-14e6-4471-8dad-7cd01766b36d/the-handshake-failed-due-to-an-unexpected-packet-format?forum=winserverwsus

    http://stackoverflow.com/questions/16895484/getting-handshake-failed-unexpected-packet-format-when-using-webclient-uploa

    Sounds likely related to SSL-misconfiguration ?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Monday, January 11, 2016 11:59 PM
  • Sounds likely related to SSL-misconfiguration ?


    I don't think I set up SSL. The clients are connecting through http://"ServerIP":8530

    Reading both those links I am still lost on what to do to fix it.  I do not need to use SSL I don't think.


    Tuesday, January 12, 2016 12:08 AM
  • I agree, you don't *need* to use SSL, it was just a thought that *may* be using SSL.. :)

    I found these after a bit more searching of the web:

    http://www.wsus.info/index.php?showtopic=13966

    https://technet.microsoft.com/en-us/library/cc708630(v=ws.10).aspx

    But, let's get back to your implementation scenario..

    This WSUS is configured as a SUP in your ConfigMgr hierarchy?
    Or, is this WSUS acting as an upstream server (it sync's to MSFT) and the ConfigMgr SUP is downstream from this WSUS box?

    I'm thinking that if this box is configured as a SUP, then you should expect ConfigMgr to be poking at this box around hourly (because that's what ConfigMgr does to WSUS). If so, is ConfigMgr setup for SUP settings that it's trying to re-assert periodically, and those settings aren't correct? (i.e. is it breaking things by asserting an incorrect config?)

    There are several ConfigMgr logs relating to WSUS interaction which you will find.

    There are also WSUS logs (c:\program files\update services\logs) worth looking into.


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, January 12, 2016 3:07 AM
  • Thank you Don..  I appreciate your replies.   I too suspected some sort of communication issue.  In my digging in the event viewer and searching logs I dug into the wcm.log file where it confirmed that there was a communication failure to the SUP.   I removed the SUP role and reset the SUP role back up and so far the log shows success and WSUS and the MMC seem to work.   I think the only difference is this time I put in specific credentials using the SCCM service account I set up.   

    Fingers crossed that this was it and it is still working in the morning.   I have so many clients with errors because they cannot download updates because WSUS is not available for the time needed.

    Thank you again for your replies and assistance.

    Tuesday, January 12, 2016 3:58 AM
  • Spoke too soon I guess. Came in this morning and launched the WSUS MMC and got the connection error. Here is the WCM Log file if that will help. I modified it slightly to get rid of domain names and server names with generic entries.

    Here are some parts of the log file since I cannot paste the whole thing.

    Updating active SUP groups...~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:18.762+360><thread=8040 (0x1F68)>
    Waiting for changes for 1 minutes  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:18.762+360><thread=8040 (0x1F68)>
    Wait timed out after 0 minutes while waiting for at least one trigger event.  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:19.777+360><thread=8040 (0x1F68)>
    Timed Out...~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:29.981+360><thread=8040 (0x1F68)>
    Checking for supported version of WSUS (min WSUS 3.0 SP2 + KB2720211 + KB2734608)~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:29.996+360><thread=8040 (0x1F68)>
    Checking runtime v2.0.50727...~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:29.996+360><thread=8040 (0x1F68)>
    Failed to create assembly name object for Microsoft.UpdateServices.Administration. Error = 0x80131701.~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:29.996+360><thread=8040 (0x1F68)>
    Checking runtime v4.0.30319...~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:29.996+360><thread=8040 (0x1F68)>
    Found supported assembly Microsoft.UpdateServices.Administration version 4.0.0.0, file version 6.3.9600.16384~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:29.996+360><thread=8040 (0x1F68)>
    Found supported assembly Microsoft.UpdateServices.BaseApi version 4.0.0.0, file version 6.3.9600.18057~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:29.996+360><thread=8040 (0x1F68)>
    Supported WSUS version found~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:29.996+360><thread=8040 (0x1F68)>
    Using DOMAIN\sccmadmin credentials for network connections~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:04:30.293+360><thread=8040 (0x1F68)>

    and

    System.Net.WebException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. ---> System.IO.IOException: Unable to read data from the transport connection: An existing

    connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host~~   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32

    size)~~   --- End of inner exception stack trace ---~~   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)~~   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)~~   at

    System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)~~   --- End of inner exception stack trace ---~~   at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest

    and

    Using DOMAIN\sccmadmin credentials for network connections~  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:11:21.875+360><thread=8040 (0x1F68)>
    Attempting connection to WSUS server: SCCM-WSUS-SERVER.domain.com, port: 8530, useSSL: False  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:11:21.875+360><thread=8040 (0x1F68)>
    System.Net.WebException: The request failed with HTTP status 503: Service Unavailable.~~   at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)~~   at

    Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber)  $$<SMS_WSUS_CONFIGURATION_MANAGER><01-12-2016 06:11:21.891+360><thread=8040 (0x1F68)>

    Something is causing a timeout but I do not know what. 

    Tuesday, January 12, 2016 1:39 PM
  • So it looks like WCM is suffering in the same kind of way that the WSUS console is..

    The webservice for WSUS, or IIS itself, is being overloaded or is hanging?

    wsusutil checkhealth, which runs periodically and logs to the event log, can be run on-demand when you have this issue, check the event logs, see if it detects anything useful?

    https://technet.microsoft.com/en-us/library/cc708604(v=ws.10).aspx

    IIS logs may reveal something? when the issue is present, can other IIS sites be accessed?

    If I understand your implementation correctly, you have CM12 and WSUS co-hosted on a single box, with the CM SQL DB running on a separate box. I'm not clear on how your SUSDB is hosted, but regardless, if the box is stressed, the service timeout could be a symptom of that?

    Has this ever worked correctly?
    Is the box generously equipped with CPU/RAM/disk etc? (maybe a performance issue?)


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, January 12, 2016 8:54 PM
  • Hi bwilkerson217,

    >The WSUS administration console was unable to connect to the WSUS Server via the remote API.

    In addition, if you install WSUS and SCCM on the same host, we couldn't use WSUS Administration Console to configure WSUS settings.

    You may click the following link to check detailed information:

    https://technet.microsoft.com/en-us/library/hh237372.aspx

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Wednesday, January 13, 2016 8:17 AM
  • Turns out it was a performance issue. I forgot to come back and say I solved it by increasing the memory allocated in IIS for WSUS. I don't have the exact details but the box running this has 16GB of ram allocated, 4 Xeon CPU Cores and 2 Gig NICs teamed for throughput.
    Thursday, February 4, 2016 1:35 AM