One of my customers experienced an issue where Outlook clients randomly lost their HTTPS connection to the Exchange server. All Outlook clients at my customer connect to the Exchange server using http/RPC rather then TCP (MAPI) both internally and externally. Randomly once a day the Outlook HTTP connection would break and fall back to TCP (internally) or break completely for external users.
Running iisreset would fix the problem but the problem would always re-emerge.
To ensure that Outlook clients retain their connection with the Exchange server using HTTP and not TCP both "On fast networks, conect using HTTP first" and "On slow networks, connect using HTTP first" must be selected.
Activesync and webmail continued to work ok and were not effected by this issue.
This issue was caused by the RPC web application using te Default Application Pool (DefaultAppPool) which is configured to recycle worker processes every 1740 minutes (29 hours). During the recycling process, IIS allows active worker threads an additional 90 seconds to finish servicing requests before IIS terminates the active threads.
Because RPC over HTTP uses long-running connections, the connections may not finish within an additional 90 secosd that were given to the worker threads. In this scenario, the connections are terminated. Therefore Outlook loses connectivity with IIS. When this action occurs, Outlook immediately tries to reconnect. If many Outlook clients are disconnected at the same time, the large number of concurrent reconnections may overwhelm the server.
To resolve this problem create a new Application Pool dedicated to the RPC over HTTP web application with a larger HTTP sys que limit. Please refer to the following TechNet article with instructions on how to perform this procedure:
http://technet.microsoft.com/en-us/library/dd421855.aspx
Running iisreset would fix the problem but the problem would always re-emerge.
To ensure that Outlook clients retain their connection with the Exchange server using HTTP and not TCP both "On fast networks, conect using HTTP first" and "On slow networks, connect using HTTP first" must be selected.
Activesync and webmail continued to work ok and were not effected by this issue.
This issue was caused by the RPC web application using te Default Application Pool (DefaultAppPool) which is configured to recycle worker processes every 1740 minutes (29 hours). During the recycling process, IIS allows active worker threads an additional 90 seconds to finish servicing requests before IIS terminates the active threads.
Because RPC over HTTP uses long-running connections, the connections may not finish within an additional 90 secosd that were given to the worker threads. In this scenario, the connections are terminated. Therefore Outlook loses connectivity with IIS. When this action occurs, Outlook immediately tries to reconnect. If many Outlook clients are disconnected at the same time, the large number of concurrent reconnections may overwhelm the server.
To resolve this problem create a new Application Pool dedicated to the RPC over HTTP web application with a larger HTTP sys que limit. Please refer to the following TechNet article with instructions on how to perform this procedure:
http://technet.microsoft.com/en-us/library/dd421855.aspx
Out of curiosity, why not use TCP? Have just had MANY hours on phone with MS trying to avoid Outlook connecting via HTTPS when on the LAN to avoid password pop-ups.
ReplyDeleteMicrosoft is moving towards HTTPS for internal and external, this is evident if you move towards Exchange 2013 with the removal of CAS Arrays.
ReplyDelete