Force Outlook 2016 to use HTTP

Jay Schwegler
Jay Schwegler used Ask the Experts™
I have a connection issue when using Outlook 2016 to connect to my Exchange 2010 server externally using Outlook anywhere.

Historically with any previous version of Outlook I needed to tell it to use HTTP on slow/fast the proxy tab via Outlook. As long as did this, external clients would connect immediately and everything worked fine. If didn't do this, Outlook would always try tcp first, which would produce a very long connection delay since RPC/TCP won't work externally. After it timed out, it would then connect via HTTP and everything would work fine after that.

In Outlook 2016, that proxy tab is gone, so as a result I get a big 30 second delay before Outlook switches to HTTP and everything works fine.

I can see through the Outlook Connectivity monitor that it is trying TCP first, causing the delay. Without the proxy tab, how can I tell Outlook 2016 to just use HTTP and be done with it?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
AmitIT Architect
Distinguished Expert 2017

Can you check this article:

Test it and see, if that resolves your issue.
I actually tried that, I found that same article a little while back, but it doesn't appear to have any effect. Also, I don't think that it is actually trying RPC/MAPI, what I'm seeing on the initial connection is that it is trying RPC/TCP, which is what the on domain clients use my default.
Most Valuable Expert 2014

You shouldn't be getting a delay with Outlook Anywhere, simple as that.
The version of Outlook shouldn't matter - if you were doing something before to make it work then it wasn't working as designed. Furthermore if you were setting the option for both fast and slow networks and that setting was sticking, then again it wasn't working as designed as Autodiscover should have "fixed" that.

Therefore you need to approach this from the other side. Instead of trying to deal with the delay, you need to establish why the delay is occuring.

There are two main reasons for the delays...

1. Autodiscover isn't working properly.
2. The name of the Exchange server resolves externally to something invalid.

Both of the above are usually DNS related.

For example, if your Exchange server is and you have a wildcard in the public domain that means it resolves to your web site, then Outlook will sit there trying to connect. For Outlook Anywhere to connect immediately the host name of the Exchange server (ie its REAL name) needs to fail to resolve.

Autodiscover isn't really optional, and Outlook 2016 only uses Autodiscover to work. Therefore you need to look at why it isn't working, or if you have never set it up correctly, correct the configuration.

Should you be charging more for IT Services?

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Thanks for responding.

Yes, I have been over all of the autodiscover stuff. At least everything that I know.

I have run through the Microsoft Exchange Connectivity Analyzer, everything for the domain comes up fine without any failure points. The only soft failure point is that my root domain happens to answer HTTPS and the certificate doesn't match, but it moves on and uses the autodiscover address without any meaningful delay.

Exchange Server internally and externally have the same hostname. SAN certificate contains the server address as well as the autodiscover address. A Record for the server name matches as well as the CNAME record for autodiscover.

Setting up the profile is no problem, it zips right though and finishes in a few seconds. It's just the initial connection where the delay appears to be.

I have no doubt that it is a configuration type issue, but I've gone through everything that I know how to check.

The reason why I have been fixated on the Outlook thing is the little fast/slow checkbox that forces HTTP was what eliminates that delay in any previous version of Outlook.
Most Valuable Expert 2014
I think your fixation on the behaviour of Outlook is wrong. As I wrote above, even if you do "fix" Outlook, a properly functioning environment will put it back to how it should be configured automatically via Autodiscover, so you will be wasting your time. The fact that you had a delay in previous versions suggests that something is not working correctly because the "fix" you have applied is not required.

The root of the domain responding to HTTPS shouldn't be an issue. It only causes a problem if there is also Autodiscover involved.

However if the real name of the Exchange server is the same (so your server is called mail, the domain is AND you are using as the host names for web services, Outlook Anywhere etc) then that is going to be cause of your problems.

Outlook Anywhere is dependant on the real name of the Exchange server to NOT resolve. If it resolves then Outlook will attempt to connect via TCP and you see the delay.
The behaviour of Autodiscover doesn't matter, which would explain why it works correctly.

The only fix is to resolve the configuration of Exchange, NOT fix the clients.

That means the real name of the Exchange server must not resolve externally and a new host name would need to be used for the HTTPS based services, along with updated SSL certificate.

Depending on the number of clients involved, that could mean some significant work because you would have to update all clients before the old name can be removed. The easiest option though would be to change the name of the Exchange server - which isn't possible.  
However as it is Exchange 2010, there is another fix - deploy an RPC CAS Array.
That is simply a DNS entry and a modification to the configuration of the databases. Use a new host name that doesn't resolve externally ( with NO wildcard in your external DNS).
Then on all Outlook Anywhere clients, repair the Outlook profile. That will force them to pick up the CAS Array address. You should then find the delays go away as the client is not trying to connect to the Exchange server via TCP first.

Being blunt, it was the wrong choice to use the same name everywhere. Exchange doesn't like that. The server name needs to be internal only, with other host names used for external traffic.

This is very valuable insight. Yes, both internally and externally the hostname is exactly the same and your explanation makes it pretty clear that this is indeed what the problem is.

I have very few Outlook Anywhere clients, which is why this never developed into a huge problem. I will investigate the RPC CAS Array as a solution.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial