Exchange 2013 Slowness With Non-Cached Outlook Clients


I just completed an Exchange 2007 to Exchange 2013 CU5 migration for a client that has about 80 mailboxes (though currently the Exch2007 server is still in place with no mailboxes on it).  Everything went relatively well.  About the only show stopping issue I ran into was mobile device non-access for users that didn't have Inheritable Perms set in Advanced settings on their AD object.

However, I'm also getting complaints of slow Outlook performance on three physical terminal servers with Outlook 2010 running in non-cached mode.  Specifically users are complaining that when they reply to email, it can take 3-5 seconds for the reply window to pop-up.  I verified this by logging in as one of the users onto one of the terminal servers.  Of course if I turn on cached mode, replies don't lag on the TS, but that isn't optimal in this environment with this amount of email.  Outlook installed and run directly on the Exchange server doesn't experience the same lag in non-cached mode.  However, if I turn on the "Show Network Connectivity Changes" notification (right-click Outlook tray icon, check it) Outlook continually pops up messages saying it has lost connectivity/been restored.  Because I just learned in the last hour that connectivity to Exchange 2013 is ONLY RPC/HTTPS now, I don't know if this continual HTTPS drop/reconnect is normal.  Again, I'm seeing this in Outlook running directly on the Exchange server.

Exchange 2013 is running on a Win2012 Standard virtual server on a host running VMWare 5.5.  The Exchange server has been allocated 16GB of memory, 8 CPU cores, a vmxnet3 adaptor, VMware Tools is installed, High Latency setting has been applied with fully reserved memory and CPU.  IPv6 is disabled on the server via the registry.  The server is fully patched.  Throughput tests from the terminal servers to the Exchange server shows results typical of GB speeds.  OWA works fine and is peppy.  I also created a new throttling policy in Exchange with most of the settings set to unlimited and applied it to the mailbox I'm testing with.

Does anyone have any insight on what to look at to troubleshoot this, or is this the new standard for RPC/HTTPS only connections in non-cached mode?

Thank you.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Adam FarageEnterprise ArchCommented:
Outlook continually pops up messages saying it has lost connectivity/been restored.  Because I just learned in the last hour that connectivity to Exchange 2013 is ONLY RPC/HTTPS now, I don't know if this continual HTTPS drop/reconnect is normal

You have two options starting in Exchange 2013 CU4 (which is SP1), which is HTTP/RPC or HTTP/MAPI. I have seen some significant issues with HTTP/MAPI, so I would say stick with HTTP/RPC... so due to the changes within Exchange 2013 there is no more MAPI/TCP connections (also known as MAPI.NET), but it is all Outlook Anywhere.

To further answer your question though, no it is not normal. I would look at the CAS connectivity on the networking level, and then the performance level on the server. Generally when you see disconnects like this its due to a bad NIC driver, networking issues (e.g: packet loss or CRC errors on the port) or a resource consumption (CPU / MEM).

Also look through the Event Viewer: Application logs... but typically this leads back to something other than Exchange (Exchange is just the symptom to the larger issue).
SafetyNet-TCAuthor Commented:
I opened a case with Microsoft.  This ended up being an issue with Dynamics CRM and the Outlook add-in for the same.  The version of CRM they have isn't optimized for Exchange 2013.  They fast-tracked a CRM upgrade to hopefully mitigate this.

Thanks for your response though.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SafetyNet-TCAuthor Commented:
Self resolved.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

We have the same problem but with Outlook 2007 on an RDS setup. Outlook 2007 does not have cachemode in RDS. So no workaround as well.

No CRM installed. But still everyone is disconnecting from outlook and reconnecting.
To bad, the 00036601 key isn't working for us. Outlook keeps being in online mode.
I wouldn't need the cachemode if outlook wouldn't be losing connection for the users during the workday. It's like the RDS is running out of connections to make.

We're already using HTTPS/RPC, so it souldn't be making MAPI connections.
SafetyNet-TCAuthor Commented:
Have you looked at raising the client throttling limits on the Exchange side?  That sounds like the issue.
The outlook 2007 caching problem is not needed anymore. In RDS we can just user online mode. The connection problems are solved:
SafetyNet-TCAuthor Commented:
Excellent! Good catch. :-)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.