Forcing Outlook Anywhere connection on internal clients

For various routing and security reasons, we've decided it would be best if all internal Outlook 2013 clients access the in-house Exchange 2013 server (at another site) from an external connection (using Outlook Anywhere) instead of going through the site-to-site VPN.

Assume internal hostname is and external hostname is

To achieve this, the following steps have been taken:
1. CNAME setup in internal DNS pointing autodiscover to
2. Autodiscover SPC in AD sites and services changed to
3. Run Set-OutlookProvider expr -certprincipalname:"" on the Exchange server.

Initial test machines worked fine - but as we started to roll out we saw some odd results.

Machines that had routes to the mail server via the VPN had their Outlook Anywhere proxy set to - and they worked fine.

Machines that didn't have routes to the mail server had their OA proxy set to - autodiscover worked fine, but then after that they couldn't authenticate.

Most oddly, a non-domain machine on an external connection that can't even resolve the internal hostname, let alone connect to it, has had its proxy set to - and it works!?

Can someone clarify what might be happening here?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

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.

Simon Butler (Sembee)ConsultantCommented:
Exchange 2013 doesn't use the internal name of the server anywhere, so the real name of the server is completely irrelevant.

The only things that are relevant are the host names configured within Exchange for Outlook Anywhere.

Using different names internally and externally is now an unusual configuration. Most implementations will use the same name internally and externally.

The only reason I can think of that your internal name is working for an external client is that you have a wildcard in your external DNS that points that host name to the externally facing server.

devon-ladAuthor Commented:

Outlook Anywhere settings show for Internal URL and for the External URL.

If I do an nslookup on from the external client it reports non-existent domain, so no wildcards in play.

Although proxy settings in Outlook show, if I look at the Outlook connection status it shows is being used ??

However, this oddity is not the main issue at the moment - the main issue is that internal clients that don't have direct access via the VPN do not seem to be able to connect.

Are the steps I've taken as listed correct/necessary - or were those unnecessary/incorrect.  The machines I was initially testing on did not work until these configs had been applied.
devon-ladAuthor Commented:
BTW Simon, did you used to do Windows Mobile development around 15 years ago?
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

devon-ladAuthor Commented:
Seems like if we avoid autodiscover and manually setup Outlook Anywhere with NTLM authentication we can connect to the mailbox.  But anything to do with autodiscover is prompting for passwords.

Outlook Anywhere is set to Negotiate on the server - maybe this should be set specifically to NTLM?
Simon Butler (Sembee)ConsultantCommented:
Never done any kind of development - let alone for Windows Mobile.

You cannot bypass Autodiscover - it must be used because on Exchange 2013 the server address is unique for each user.

Authentication prompts don't always mean Authentication issues -  the most common cause is SSL certificate problems - name mismatch etc.

Negotiate authentication should work for everything but Windows XP, unless something is getting in the way. You can try NTLM on the server, see if that allows the connection. However if it does not, then something is breaking the authentication process. That isn't unusual on Outlook Anywhere and usually means the client has to use Basic. However it should fail back on its own.

devon-ladAuthor Commented:
Your name was familiar and the details on your blog looked like you might be the same chap.

Listen, think I've been wasting your time due to sleep deprivation provided by our unsettled toddler.

The underlying issue is that there was no internal route from the clients to the Exchange box - hence the reason for having to make an external connection.

Completely overlooked the fact that it's trying http to the internal address first, and that will be going through the proxy, and the proxy has a route to the box internally.

Just needed a bypass rule on the proxy to the internal name!

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
devon-ladAuthor Commented:
Found solution myself but useful comments from Simon
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.