VMware Cloud Community
kungpow
Enthusiast
Enthusiast

VMware ESXi 5.5 U2 - TcpAckFrequency

Looks like there is a bug in VMware ESXi.

Exchange 2013 SP1 on win2k12 r2 on a physical server: no slow upload issue with Outlook.

Exchange 2013 SP1 on win2k12 r2 on VMware ESXi 5.5 U2: has slow upload issue with Outlook.

-tried E100E & VMXNET3 network adapters, doesn't fix the issue.

-only way to fix the slow upload issue is to modify the registry key TcpAckFrequency on the PC

How do I fix this in ESXi without modifying TcpAckFrequency in the registry on the PC?

Thanks

45 Replies
welder314
Enthusiast
Enthusiast

Same Exchange issue here, 2013 on Server 2012R2, ESXi build 2323236 (5.1 U3).  Outlook 2013 on Windows 7.  Like everyone else, I have observed that downgrading to VMware Tools 5.1 U1 on the servers, or disabling delayed ACK client side, seems to fix the problem.

But I opened a support case because I prefer that the root cause be addressed - I don't like workarounds.  That said, I just got off the phone with VMware support, and we disabled TCP Offload and TSO on the servers:

VMware KB: Poor network performance on Windows 2008 Server virtual machine

So now I have a simple workaround that fixes the problem without modifying the clients and without having to reinstall Tools.  It also verifies that the issue lies within the vmxnet3 driver.

Anyone try 6.0 Tools?

Reply
0 Kudos
krismcewan
Enthusiast
Enthusiast

We have this issue at one of our customers.

they are running Exch 2013 on Win12R2 and ESX 5.5U2

however the TCPACK fix is not suitable as they are running View linked clones and these have new GUIDs every time they are reprovisioned.

Installing older tools isn't an option as this could introduce even more variables into View than it fixes. (need to keep Tools, agent versions compatible)

I am concerned about this as I have 3 other customers planning an exchange upgrade and even though not all of them are using View they will all be affected.

I have a call in to VMware at the moment and it is escalated to the VMware team.

So i would be interested to see if anyone has updates or any other fixes.

A VMware Consultant in Scotland for Taupo Consulting http://www.taupoconsulting.co.uk If you think I'm right or helpful award me some points please
Reply
0 Kudos
nettech1
Expert
Expert

krismcewan,

take the script posted on spiceworks and add it as a group policy for  View linked clones will update the registry when group policy gets processed. May need to reboot one more time after the changes are applied.

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

Reply
0 Kudos
krismcewan
Enthusiast
Enthusiast

i have found another way which i am testing now. if it fails i will give the spiceworks a go.

Powershell script called by the Post Sync on View to run as local system part of Quickprep.

the Process does a reboot anyway and hopefully it kicks in

$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}

A VMware Consultant in Scotland for Taupo Consulting http://www.taupoconsulting.co.uk If you think I'm right or helpful award me some points please
Reply
0 Kudos
JBHorne
Contributor
Contributor

We wound up rebuilding our Exchange servers from scratch and migrating all users and mailboxes to the new servers. This was a last ditch effort, but it appears to have resolved the issue. This was an identical server build -- Server 2012 R2, Exchange CU6, VMware 5.5U2.

I'd still be greatly interested to hear what VMWare says concerning this matter now that it's been several additional months.

Reply
0 Kudos
krismcewan
Enthusiast
Enthusiast

The script works.

it has to be called in View quickprep from a batch file and that batch file aslo has to initiate a reboot.

I am interested in the prev post about the rebuild.  would be interesting to see what differences were made between the 2 builds. Although askign a customer to rebuild their exchange after spending weeks on it is a non starter there could be elements they could change.

A VMware Consultant in Scotland for Taupo Consulting http://www.taupoconsulting.co.uk If you think I'm right or helpful award me some points please
Reply
0 Kudos
lobo519
Contributor
Contributor

Seeing this issue too - I opened a ticket with VMWare but they seem less than interested. To those who fixed it by downgrading VMware tools 5.1 U1 - did you downgrade on all Exchange servers or just CAS or mailbox?

Reply
0 Kudos
welder314
Enthusiast
Enthusiast

Can you guys check if the VShield drivers are installed on your server(s)?  Do an Interactive Tools install, choose Modify, and see if it's installed.

I found out that uninstalling VShield drivers on the servers (not the client) 'fixed' the problem.  (Of course this doesn't really fix the whole issue, because we use the VShield drivers for our anti virus solution)

Reply
0 Kudos
Bleeder
Hot Shot
Hot Shot

The newest VMware Tools renamed the vShield component.  If you see the name vShield, that means you have old Tools.  Check if you're running the latest tools (http://packages.vmware.com/tools/esx/5.5latest/windows/index.html).  For v5.5, they are v9.4.12.

Reply
0 Kudos
lobo519
Contributor
Contributor

I had the latest drivers (vSheild is now Guest Introspection). I uninstalled the Guest Introspection driver with the current tools and it resolved my issue. I have updated my ticket with VMware and will report back.

Reply
0 Kudos
lobo519
Contributor
Contributor

I have received a vSheild driver patch that is supposed to resolve this issue. I am told if my results show its fixed it will be made publicly available.

Reply
0 Kudos
welder314
Enthusiast
Enthusiast

lobo, can you post your case number?  I have been trying to get VMware to acknowledge this issue, but they said it was not their problem and eventually told me to call Microsoft.

Reply
0 Kudos
lobo519
Contributor
Contributor

15687236506

Reply
0 Kudos
SpongeWare
Contributor
Contributor

Hi

has someone any news to this issue?

e have the same problem here. (ESX 5.5 U2 2718055)

Thanks!

Reply
0 Kudos
SpongeWare
Contributor
Contributor

I tried yesterday vmware Tools 10.0..0.3000743  I have the same poor performance. Our hosts running on ESXi, 5.5.0, 2718055. we us vmxnet3 networkcards. Exchange 2013CU9 is runnig on wind2012R2 VM.

Test:

10.0.0. -> poor Latency on Win7 Outlook 2010

9.4.12  -> poor Latency on Win7 Outlook 2010

9.05.21789 -> Latency in Outlook 2010 OK

for me it seems to be a VMWare BUG

Reply
0 Kudos
kungpow
Enthusiast
Enthusiast

The slow upload issue hasn't been fixed in ESXi 6.0.0.

I have tested this on Exchange 2013 CU9 with win2k12 r2 on ESXi 6.0.0 and removing the following vmware tools features fixes the slow upload issue:

NSX File Introspection Driver

NSX Network Introspection Driver

Reply
0 Kudos
CodeMan47
Contributor
Contributor

Did you ever get a solution to this problem?  I'm experiencing the same and am curious if that patch worked and was ever made public.

Reply
0 Kudos
hilzz
Contributor
Contributor

I was able to resolve this problem by changing the vmware tools install and unticking (the below) and then restarting the server, all users reported outlook performing much better. always take a snapshot before any changes.

NSX File Introspection Driver

NSX Network Introspection Driver

impranayk
Enthusiast
Enthusiast

If hotfix has not yet released from Vmware, try downgrading VMTool on Virtual machine. It should fix the issue.

-------------------------------------------------------------------------
Follow me @ www.vmwareinsight.com
Please consider marking this answer "correct" or "helpful" if you found it useful

Pranay Jha | Blog: http://vmwareinsight.com
vExpert 2016/2017, VCAP5-DCD/DCA, VCP5-DCV, VCA-Cloud, VCE-CIA, MCSE, MCITP
Reply
0 Kudos
the_dude_33
Contributor
Contributor

Hi all - curious to know if anyone was able to get anymore information from VMWare regarding this issue. Currently investigating deployment of registry change for tcpackfrequency in our environment, kind of hesitant to do so given the implementation requirements, but we do want to get the problem addressed properly. Have a workaround in place, but it's not ideal.

Reply
0 Kudos