Skip to content

Exchange 2016 – Poor Outlook 2016 Performance – Troubleshooting

Exchange 2016 - Poor Outlook 2016 Performance - Troubleshooting - Server-side or Client-Side?

Just recently I came across a newly installed Exchange 2016 environment and had to analyze a "poor performance issue". I started my investigation by asking ... Google! Of course, everybody does it, but is not willing to commit it. This left me with the idea of creating another blog article on this matter. On the bottom of my blog article you'll find all relevant URLs which gave me (more or less) useful information during my time debugging the problem. As it turned out, there are multiple aspects to consider.

Client-Side

First of all you have to consider all kinds of Outlook AddIns that might tamper with your Outlook performance. A couple of users reported that specific AV AddIns, e.g. Kaspersky, cause major performance issues and thus disabled it in order to verify whether to problem goes away. And it did!

Stick closely to The Microsoft Exchange Team Blog article in your troubleshooting methodology, especially the Client Configuration.

Another issue that can be found on the client-side of things is described here:

I put in a trouble ticket with Microsoft Exchange team and been troubleshooting this issue for the past week. Today, the Microsoft tech suggested I add the TcpAckFrequency to an ailing Windows 7 box and I can confirm avg response times now in the tens. It was in the 2 - 3 hundreds before registry change. I replicated the reg fix on another Windows 7 and same result - more responsive Outlook.

  • TcpAckFrequency DWORD (32-bit) Value (set to 1) under the
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\Interfaces\<NIC GUID> node

24-06-_2016_11-32-12

The PowerShell script provided adjusts the aforementioned registry key accordingly:

$strGUIDS=[array](Get-WmiObject win32_networkadapter -filter "netconnectionstatus = 2" | select -expand GUID)
foreach ($strGUID in $strGUIDS) {New-ItemProperty -path HKLM:\System\CurrentControlSet\services\Tcpip\Parameters\Interfaces\$strGUID -propertytype DWORD -name TcpAckFrequency -value 1}

24-06-_2016_11-35-47

Server-Side

Set Power Management to “High Performance”:

24-06-_2016_09-37-12

Test your Exchange Server health with the following PowerShell scripts and fix any issues they might reveal:

24-06-_2016_09-52-14

24-06-_2016_12-21-54

Stick closely to The Microsoft Exchange Team Blog article in your troubleshooting methodology, especially the CAS configuration. The following are considered Best Practices from my point of view:

Disable IPv6 as per KB929852, but use the Automatically disable or re-enable IPv6 or its components instead, as manually fixing the problem through adjusting the corresponding registry key

  • DisabledComponents DWORD (32-bit) Value (set to 0xffffffff) under the
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters node

not always worked as expected. And you might have to consider KB3014406 - Startup delay occurs after you disable IPv6 in Windows afterwards as well.

But: in case you're using VMware virtualization technologies for your Exchange Server box you might have to consider this:

We finally found the root of this problem. It is not an exchange 2013 or Outlook issue. It is VMware. Our Exchange 2013 server runs on top of VMware 5.5. The 2012 server uses the VMXNet3 Nic. The root of this problem is with the VMXNet3 driver. The fix for this is to uninstall the VMWare 5.5 tools from the server and install the VMWare 5.1 U1 tools (The 5.1 U2 and any 5.5 tools do not work.). Once this is done there is no need to do the TCPAckFrequency registry change on any clients. You can read more here, some other guys have opened a case with VMware.

Last but not least: Sizing. Read:

Further reading:

Leave a Reply