Transmit Server Closed Connection
Server Closed Connection

Some Outlook users are reporting that they consistently get the 0x800CCCDD error (‘ Your IMAP server closed the connection ‘) whenever they send or receive emails via an IMAP account. This particular error code is signaling that the Send/Receive feature has failed. Outlook Error 0x800CCCDD with IMAP Server. Of course the question as to why the server closed your open connection on you is the mystery. Perhaps there is something in the mysql server logs to indicate why? Perhaps if you could include a packet capture of the transaction I can confirm that this module did indeed see the connection close, though that doesn't answer the why, only confirms. In the normal case, each side terminates its end of the connection by sending a special message with the FIN (finish) bit set. This message, sometimes called a FIN, serves as a connection termination request to the other device, while also possibly carrying data like a regular segment.

Symptoms

Consider the scenario where you have Outlook or other MAPI applications that connect to Exchange Server 2010 through a hardware load balancer or other network device. The application also requires long running TCP connections to function as expected. If the network device closes idle connections via a timeout setting, the MAPI application fails to complete requests over the connection.
If the application is Outlook, you may see the following events in the Application event log of the client computer:

Log Name: Application
Source: Outlook
Event ID: 25
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: Computer.contoso.com
Description:Could not perform the desired operation. The selected command is not valid for this recipient. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action..

Log Name: Application
Source: Outlook
Event ID: 26
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: Computer.contoso.com
Description:Connection to Microsoft Exchange has been restored.

Cause

A configuration for a hardware load balancer, or other network device such as a firewall or proxy, is causing client connections to drop. When the device closes idle connections, via timeout or other configuration, the application fails to complete subsequent requests over the connection that was closed.

Resolution

To resolve this issue, consider the following solutions:

Transmit Server Closed Connection

Verify the configuration of the network device, per the vendor recommendations or through contacting the Technical Support team for the vendor. This may require increasing the timeout on the network device so that long running connections are not prematurely closed.
For an application server connecting to Exchange Server 2010, set the application server's TCP Keep-Alive time to a value less than the idle connection timeout window on the network device.
For example, if the idle connection time out on the device is 15 minutes, set the TCP Keep-Alive on the application server to a value less than 15 minutes.

By default the TCP Keep-Alive time is 2 hours and disabled. To adjust the TCP Keep-Alive time on an application server see the following article from the Microsoft Knowledge Base:

324270 How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003It is important to stress that the connections in question are typically internal RPC connections for Outlook clients in Online mode, rather than RPC over HTTP/Outlook Anywhere connection. Frequently, issues such as this occur due to session timeouts, network configuration, optimization configuration or other features on the network device that require modification.
In many cases, session timeout settings are typically too low. In discussion with network device vendors, it is frequently recommended that RPC timeout settings should be 120 minutes, at a minimum.

More Information

Both of the solutions above may prevent the TCP connection from timing out prematurely.
Note A frequently used test to determine whether a device configuration is at issue is to bypass the device. This is done by using a Hosts file on the client or a DNS record to access a single CAS server in the array. However, if the device is also used as a gateway, this may not provide accurate results.
For additional information on long running connections, see section 4.2.3.6, TCP Keep-Alives, from the following Internet Engineering Task Force document:

RFC 122 - Requirements for Internet Hosts - Communication Layers
http://datatracker.ietf.org/doc/rfc1122/
For additional information on Load Balancing for Exchange Server 2010, see the following presentation from TechEd 2011

Server Closed Connection

Load Balancing with Microsoft Exchange Server 2010
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/EXL307

Re: The state server has closed an expired TCP/IP connection

Dec 07, 2018 04:12 PM|Koenemoes|LINK

We have had this issue for a couple of months at seemingly random times and levels of severity. Last week I finally got the extra hint from a seemingly unrelated event.

We also saw a 100% CPU spike on at least 1 IIS app pool which brings down the whole server after a while.

IISRESET was our only solution and this would work.

Long story short: it happened during WSUS updates of our dc's. The AD resync after rebooting them took longer than the configured time window of 1 hour.

So the situation could arise that both DNS servers were offline -> so also no AD

State server was configured as 'localhost', 127.0.0.1 would not have had this issue. I check by disassembling webengine4.dll. It returns something like 'connection closed by remote host' HRESULT 72746.

But system.web interprets this as the session being locked by a concurrent query and keeps retrying at full speed. This created an infinite loop of failing socket connections PER SESSION!

And that is why cpu got to 100%. It fills up the request queue, still waiting for the session data and then fajils completely with http 503 for all appools.

Our logs also showed connection issues to our sql because ad was down.

We were so focussed on the 100% cpu being the cause, but it was only a symptom. The fact that this error logged in event viewer was very misleading in my case.

In the end it was a quick 1 minute fix of the DC. -> no more emergency wake up calls for me :)

This was a perfect storm of timing events and small config mistakes which led to misleading logs and cpu spike by a asp.net bug...? Why keep retrying to read the session data if it won't work due to dns. Just end the webrequest there and log sometinhg like: NameResolution Failed instead of connection timeout

Transmit Server Closed Connection.