Exchange 2013 Outlook anywhere issues when InternalHostname value is set to Server FQDN
Let’s take a look at an issue where Outlook anywhere doesn’t work when InternalHostname value attribute is set to server FQDN.
This was a multi-site Exchange 2013 deployment with a 10MBPS – 30PMBS dedicated pipe running across site. We had a requirement to ensure local users contact local servers ONLY for any internal Outlook connection.
3 sites as follows:
BOS, NY and CA. In essence, we don’t want a CA user to contact the CAS server in NY for “internal” connections. NY is the internet facing site where a hardware load balancer accepts connections made to “webmail.exchguru.com”, hence changing InternalHostname value on Outlook Anywhere means all clients will go to NY at all times. You may also specify AutoDiscoverSiteScope.
One of the main drawback of doing this that you need to add the Server FQDN’s (or the DNS entry/InternalHostName URL) as a SAN in the SSL certificate on Exchange 2013. Most of the public accepted ROOT Certification authorities will not allow this. Also ensure the certificate is current on the server and it is properly selected in IIS Default website under “Bindings – Https 443”.
The first issue I faced was to retrieve virtual directory settings from servers. Every time you fire up EMS to run a cmdlet to retrieve VDir (virtual directory) settings, it will contact the IIS on that server and based upon how fast your network connectivity is, you may experience extreme slowness. So, Exchange management shell or EAC takes ages to retrieve settings. To resolve this, we can point shell to retrieve settings from Active Directory and “not to” query IIS on each and every CAS server.
Use the switch –ADPropertiesOnly to retrieve settings from Active directory if powershell is slow.
To do that, type in:
Get-OutlookAnywhere -ADPropertiesOnly |fl Identity, *auth*, *hostname
Identity : Exch2013-BOS2\Rpc (Default Web Site)
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
ExternalHostname : webmail.exchguru.com
InternalHostname : Exch2013-BOS2.exchguru.local
Identity : Exch2013-BOS1\Rpc (Default Web Site)
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
ExternalHostname : webmail.exchguru.com
InternalHostname : Exch2013-BOS1.exchguru.local
Identity : Exch2013-NY2\Rpc (Default Web Site)
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
ExternalHostname : webmail.exchguru.com
InternalHostname : Exch2013-NY2.exchguru.local
Identity : Exch2013-NY1\Rpc (Default Web Site)
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
ExternalHostname : webmail.exchguru.com
InternalHostname : Exch2013-NY1.exchguru.local
Identity : Exch2013-CA2\Rpc (Default Web Site)
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
ExternalHostname : webmail.exchguru.com
InternalHostname : Exch2013-CA2.exchguru.local
Identity : Exch2013-CA1\Rpc (Default Web Site)
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
ExternalHostname : webmail.exchguru.com
InternalHostname : Exch2013-CA1.exchguru.local
Now that you settings retrieved from all the CAS servers, compare and ensure “all” authentication settings are unique across servers. You may chose NTLM or Negotiate for Outlook anywhere, I don’t recommend Basic.
Now that we have all settings, let’s configure an internal Outlook client. Once the client is configured, do (Control + right click Outlook icon) on Task Bar and click TestEmailAutoConfiguration.
Once you have the XML file returned, take a look at the Exchange HTTP (internal) and Exchange HTTP (external) URL’s and ensure it is all configured as per requirement.
Ideally it would be https://servername/servicename for internal settings and
https://ExternalURL/servicename for External HTTP settings.
If the External HTTP settings are showing “externally” resolvable DNS value, then you don’t have to worry about what comes up in Outlook proxy connections. Even if it shows internal servername, Outlook knows what to do when it cannot contact internal server.
In my case, both where correct but Outlook still wouldn’t connect from External internet and kept giving certificate warnings.
Solution:
What worked for me was to setup OutlookProvider EXPR settings to MSSTD:webmail.exchguru.com so you are forcing Outlook to grab the EXPR (external connection) to use the public DNS value.
This should be set to the “Issued to value” on the certificate and not SAN name.
To do this,
Set-OutlookProvider EXPR -CertPrincipalName MSSTD:webmail.exchguru.com
My conclusion is that if the InternalHostname is set to “Server FQDN” and that “FQDN” is also added as SAN on the cert, I had to force the EXPR CertPrincipalName for OA to work externally.
Please contact Microsoft support if you have questions on this.
Ratish Nair
Microsoft MVP | Exchange Server
Team @MSExchangeGuru.com
Keywords: Outlook anywhere not working, Exchange 2013 Outlook anywhere issues, InternalHostName, ExternalHostName, How to configure Outlook anywhere.
October 28th, 2013 at 3:46 pm
Hi Ratish,
Couldn’t this have been achieved with AutoDiscoverSiteScope?
Best Regards,
Jesper
October 28th, 2013 at 4:05 pm
yes – agreed and its setup already. I will add it to the article.
My customer “wanted” to use servernames 🙁
Main focus was on having to set “CertprincipalName” on EXPR which isnt a standard configuration…
December 17th, 2013 at 8:29 pm
Ratish,
For internal connections, you can also turn off SSL.
When you do this, the Certificate issue go away and you can use the name of the CAS directly in your Exchange Proxy value for outlook.
Remember that even though the connection is “technically” not encrypted, the internal RPC data IS encrypted by default (unless you change Outlook’s RPC Encryption flag). So, the only thing that might be sensitive that is passed clear is the authentication to IIS to build the RPC/HTTP tunnel. If this is on the internal network, this is the same level of connection you had with RPC/MAPI, as long as you don’t use Basic auth (which you cannot when you turn off SSL).
The drawback with this or even with your current approach is for users that travel. They would likely have to have 2 outlook profiles for their mailbox: one while in the org boundary and one while external.
July 13th, 2017 at 8:06 am
My problem is: i use a Exchege Server 2016, when i do login in owa no problem this worked fine, but i do logout i receive this messege ERR_TOO_MANY_REDIRECTS, from a long time looking a solution for this, but nothing
I hope you can help me
Im writting from venezuela
Regards
July 15th, 2017 at 3:01 am
I have seen this. if you redirect to the same url and it falls in the loop then you will see too many redirects. Last week I had fixed for a customer.