Thanks Macster and Festivalman for this tip !

Before applying this TCP Ack solution, the below conditions must be met:

- OWA connection and mail browsing is very fine, whereas an Outlook online mode (i.e. not cached mode) connectivity is quite sluggish when mailboxes are on Exchange 2013…

- If OWA is slow as well, then the issue may be a general network slowness issue – check the network latency using Ping or PsPing (Advanced ping tool from Windows SysInternals)

- On Outlook Connection Status dialog box (CTRL+Right Click the Outlook icon on the Windows notifications part of the taskbar), Avg. Proc. time is fine, below 50~60ms, and Avg. Resp. time is over 110ms.

Cause:

Cause seems that it looks like it’s caused by the 200ms timeout setting on ACKs, probably causing more TCP retransmits – using Netmon and an Outlook connecting to an Exchange 2013 lab infrastructure may confirm that point …

To summarize Macster and Festivalman findings, the solution is to create a TcpAckFrequency registry key and set it to 1.

Recommendation:

My recommendation is not to change this registry key on the desktop(s) until you confirmed the behavior using a Network Trace, and until you are falling Under the above mentionned conditions (especially OWA browsing is fine, Outlook online browsing is slow)

More information about the TcpAckFrequency registry key:

Quoting from http://support2.microsoft.com/kb/328890:

- TcpAckFrequency is a registry entry that determines the number of TCP acknowledgments (ACKs) that will be outstanding before the delayed ACK timer is ignored.

- TCP uses delayed acknowledgments to reduce the number of packets that are sent on the media (Wifi, Wire,…)

- As data is received by TCP on a particular connection, it sends an acknowledgment back only if one of the following conditions is true:

• No acknowledgment was sent for the previous segment received.
• A segment is received, but no other segment arrives within 200 milliseconds for that connection.

Typically, an acknowledgment is sent for every other TCP segment that is received on a connection unless the delayed ACK timer (200 milliseconds) expires.

- You can adjust the delayed ACK timer by editing the following registry entry.

Subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID>

Entry:

TcpAckFrequency

Value Type: REG_DWORD, number
Valid Range: 0-255
Default: 2
Description: Specifies the number of ACKs that will be outstanding before the delayed ACK timer is ignored. Microsoft does not recommend changing the default value without careful study of the environment.

More explanations and complete solution:

Outlook slow after migrating to Exchange 2013

http://community.spiceworks.com/topic/571571-outlook-slow-after-migrating-to-exchange-2013

Slow online mode "browsing"

https://social.technet.microsoft.com/Forums/office/en-US/0d45b1b0-3047-4666-ad04-217e98ed8823/slow-online-mode-browsing?forum=exchangesvrclients

Again, to give back to Caesar what belong to Caesar, thanks to Macster and Festivalman for sharing this finding ! That will save trouble for many people out there !

Cheers,

Sam.

Hi all,

a quick word about this SSL 3.0 vulnerability and Exchange Server, as there is nothing specific to Exchange regarding our recommendations.

Microsoft Suggested Actions to mitigate or eliminate the SSL 3.0 vulnerability are to disable 3.0 usage on clients (browsers, devices) and servers, although this vulnerability is not a huge security threat, in the sense that the attacker must show up in the middle of a Client <-> Server SSL session to perform his attack and as per the below mitigation factor from the Technet’s vulnerability detailed description:

Mitigating Factors:

· The attacker must make several hundred HTTPS requests before the attack could be successful.

· TLS 1.0, TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.

Then, disabling the use of SSL v3 on the client will prevent all clients to use SSL v3.0 to establish SSL channels, these will use TLS instead; the consequence of this is for services (applications servers) who don’t support TLS, who only rely on SSL 3.0 for SSL encryption => clients/browsers without support of SSL v3.0 won’t be able to access services using SSL v3.0 only; they just won’t understand other SSL encryption protocols than SSL v3.0. Exchange Server supports TLS for SSL channel encryption and then can work without SSL v3.0 as it is doing by default.

So to understand the differences between both, here is the Technet’s description which is okay to take paste here (just to not reinvent the wheel):

What is SSL? 
Secure Sockets Layer (SSL) is a cryptographic protocol that provides communication security over the Internet. SSL encrypts the data transported over the network, using cryptography for privacy and a keyed message authentication code for message reliability.

What is TLS?
Transport Layer Security (TLS) is a standard protocol that is used to provide secure web communications on the Internet or on intranets. It enables clients to authenticate servers or, optionally, servers to authenticate clients. It also provides a secure channel by encrypting communications. TLS is the latest version of the Secure Sockets Layer (SSL) protocol.

So disabling SSL V3.0 on the Windows Server hosting Exchange server application won’t affect classical Exchange services, it will only prevent clients that cannot/don’t “speak” TLS (who speak SSL 2.0/3.0 only) to connect to Exchange services using SSL channel.

All the other clients such as Outlook and IE will continue to work seamlessly with the Exchange services.

Disable SSL 3.0 in Windows

You can disable support for the SSL 3.0 protocol on Windows by following these steps:

1. Click Start, click Run, type regedt32 or type regedit, and then click OK.

2. In Registry Editor, locate the following registry key:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\SSL 3.0\Server

Note If the complete registry key path does not exist, you can create it by expanding the available keys and using the New -> Key option from the Edit menu.

3. On the Edit menu, click Add Value.

4. In the Data Type list, click DWORD.

5. In the Value Name box, type Enabled, and then click OK.

Note If this value is present, double-click the value to edit its current value.

6. Type 00000000 in Binary Editor to set the value of the new key equal to "0".

7. Click OK. Restart the computer.

Note This workaround will disable SSL 3.0 for all server software installed on a system, including IIS.

Note After applying this workaround, clients that rely only on SSL 3.0 will not be able to communicate with the server.

(Source: https://technet.microsoft.com/en-us/library/security/3009008.aspx)

More information:

Details about the POODLE attack on the SSL 3.0 vulnerability:

http://www.theregister.co.uk/2014/10/16/poodle_analysis/

One of the security researchers says as well:

“The conditions that are required for the attack to be applicable are hard to obtain. In particular, the attacker needs to become a man-in-the-middle between the attacked client and server, and to generate, block and modify client messages to the server and vice versa."

Testing your client vulnerability to Poodle attacks/hijacks:

https://www.poodletest.com/ 

Hope this helps you understand a bit better what’s up with Exchange and this SSL 3.0 vulnerability,

Sam.