Don’t skip steps – don’t skim and think you’ve done this. Run through my guide very carefully and it should fix everything for you.
You need to make sure your OutlookAnywhere and AutoDiscover settings are setup properly along with Split-DNS. OutlookAnywhere and Split-DNS are vital for future-proofing your Exchange configuration and making it work properly now, regardless if you use Exchange 2007, 2010, or 2013. For Exchange 2013, OutlookAnywhere is a requirement and Split-DNS is Best Practice. If you are on Exchange 2007 or 2010, and you do not have OutlookAnywhere enabled, enable OutlookAnywhere and follow this guide.
You should always use NTLM over Basic authentication, as Basic sends the username and password in the clear, and NTLM is Windows Authentication. On Exchange 2013, you also have a new option called Negotiate, which is recommended. As you follow this guide, you will set the ClientAuthenticationMethod (Internal and External if on Exchange 2013) to NTLM and IISAuthenticationMethods to Basic,NTLM (and Basic,NTLM,Negotiate for Exchange 2013). Please also turn on SSLOffloading.
As DNS is a vital component in any network, please make sure that Split-DNS is setup first before doing anything else. To make sure Split-DNS is working properly, ping the OWA URL and AutoDiscover URL (eg. mail.domain.com and autodiscover.domain.com). These should both respond from an internal computer to the internal IP of your Exchange server (eg. 192.168.1.55). Then from an external source, ping the OWA URL and AutoDiscover URL (eg. mail.domain.com and autodiscover.domain.com). They should both respond externally to your external IP of the mail server (eg. 126.96.36.199). To confirm that Split-DNS is working correctly:
From an internal computer:
ping mail.domain.com ping autodiscover.domain.com
These should resolve to your internal IP of your mail server (eg. 192.168.1.55).
From an external computer:
ping mail.domain.com ping autodiscover.domain.com
These should resolve to your external IP of your mail server (eg. 188.8.131.52).
To fix the external records (more than likely, autodiscover is the one that doesn’t exist and needs to be created), on your domain’s name servers create an A record for autodiscover.domain.com and point it to the external IP of your mail server (eg. 184.108.40.206).
To fix the internal records, the easiest way to do this is to create a DNS Zone (Active Directory – Integrated) for mail.domain.com (assuming that is your OWA URL) and then create a blank A Record and point it to your internal IP Address for your mail server (eg. 192.168.1.55). Then create another DNS Zone (Active Directory – Integrated) for autodiscover.domain.com and create a blank A record and point it to the internal IP Address of your mail server (eg. 192.168.1.55).
After Split-DNS is confirmed working, the next thing to check is the Virtual Directories and the Client Access Server Autodiscover URI and fix them accordingly too. All InternalUrl and ExternalUrl’s should be setup using the hostname mail.domain.com (assuming mail.domain.com is the OWA URL that you chose).
If some of these Exchange PowerShell commands error out, don’t worry, these are to provide everything from Exchange 2013 back to 2007. Run these commands and keep them as a text file as a backup of what you currently have for settings should you need to reference what something used to be.
Get-OutlookProvider | fl Get-OutlookAnywhere | fl Get-ClientAccessServer | fl Get-ActiveSyncVirtualDirectory | fl Get-AutodiscoverVirtualDirectory | fl Get-EcpVirtualDirectory | fl Get-OabVirtualDirectory | fl Get-OwaVirtualDirectory | fl Get-PowerShellVirtualDirectory | fl Get-WebServicesVirtualDirectory | fl
After taking a backup of the output above, let’s proceed with the steps to fix your environment. Change the ExternalClientAuthenticationMethod (ClientAuthenticationMethod on Exchange 2010) to NTLM and turn on SSLOffloading. If you’re on Exchange 2013, with all Outlook 2013+ clients, I would suggest setting ExternalClientAuthenticationMethod, InternalClientAuthenticationMethod and IISAuthenticationMethods to Negotiate, otherwise, keept it with NTLM for backwards compatability of Outlook 2010 and Outlook 2007 clients.
For Exchange 2010
Set-OutlookAnywhere -Identity "SERVER\Rpc (Default Web Site)" -SSLOffloading $true -ClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM
For Exchange 2013
Set-OutlookAnywhere -Identity "SERVER\Rpc (Default Web Site)" -SSLOffloading $true -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM,Negotiate
Set-OutlookAnywhere -Identity "SERVER\Rpc (Default Web Site)" -SSLOffloading $true -ExternalClientAuthenticationMethod Negotiate -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Basic,NTLM,Negotiate
Set the CertPrincipalName for the OutlookProvider settings.
Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:(Subject name of certificate) Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:(Subject name of certificate) Set-OutlookProvider -Identity WEB -CertPrincipalName msstd:(Subject name of certificate)
Set the CAS Autodiscover to the OWA Hostname:
Set-ClientAccessServer -Identity "SERVER" -AutoDiscoverServiceInternalUri "https://OWAHOSTNAME/Autodiscover/Autodiscover.xml"
Set All VirtualDirectories to the OWA Hostname except for the AutodiscoverVirtualDirectory which stays blank for InternalURL and ExternalURL.
Set-ActiveSyncVirtualDirectory -Identity "SERVER\Microsoft-Server-ActiveSync (Default Web Site)" -ActiveSyncServer "https://OWAHOSTNAME/Microsoft-Server-ActiveSync" -InternalUrl "https://OWAHOSTNAME/Microsoft-Server-ActiveSync" -ExternalUrl "https://OWAHOSTNAME/Microsoft-Server-ActiveSync" Set-EcpVirtualDirectory -Identity "SERVER\ecp (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/ecp" -ExternalUrl "https://OWAHOSTNAME/ecp" Set-OabVirtualDirectory -Identity "SERVER\OAB (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/OAB" -ExternalUrl "https://OWAHOSTNAME/OAB" -RequireSSL $true Set-OwaVirtualDirectory -Identity "SERVER\owa (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/owa" -ExternalUrl "https://OWAHOSTNAME/owa" Set-PowerShellVirtualDirectory -Identity "SERVER\PowerShell (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/powershell" -ExternalUrl "https://OWAHOSTNAME/powershell" Set-WebServicesVirtualDirectory -Identity "SERVER\EWS (Default Web Site)" -InternalUrl "https://OWAHOSTNAME/ews/exchange.asmx" -ExternalUrl "https://OWAHOSTNAME/ews/exchange.asmx" -InternalNLBBypassUrl $null
Restart IIS and the Microsoft Exchange Transport Services
Another thing that is really handy, is to make OWA accessible by http redirecting to https so that your users don’t have to remember to type https. The easiest and best way that I’ve found to do this is to edit the Default Website’s Error Pages and set the 403 error to redirect to https://mail.domain.com/owa. You will need to re-apply this after every Cumulative Update (CU) that you perform as the CUs will revert these settings to defaults.
To do this:
- Open IIS
- Navigate to the Default Web Site on the left.
- On the right, double click on Error Pages
- Double click on the 403 Status Code.
- Change the Response Action to “Respond with a 302 redirect” and in the Absolute URL: type in https://mail.domain.com/owa
- Press OK and close IIS.
- Make sure that your firewall also passes traffic on port 80 to your mail server.
- In your browser, type in mail.domain.com and hit enter. It should find it and redirect you to the OWA Login.
If you don’t already have a proper 3rd party certificate, I would suggest taking the plunge for $29.88 USD
NameCheap has PositiveSSL Multi Domain certs with the first 3 hostnames included.
You’re going to need at least 2 – mail.domain.com (OWA URL, and Subject of the Cert) and autodiscover.domain.com (Subject Alternative Name – or SAN). A wildcard certificate will work, but a SAN certificate is best practice as if a wildcard certificate is compromised, any name can be secured, but if a SAN certificate is compromised, then only those hostnames specified can be secured.
The time it will take you to troubleshoot trying to use a self-signed certificate or one from an in-house CA (if you have one)… will cost your company more money in terms of time than just buying a certificate using the link I gave you above. Oh, and I don’t make any commission or anything from that link – it’s a direct link to the SSL Cert you need.
Also, for Exchange testing, (Autodiscover and Connectivity) you can use Microsoft’s TestConnectivity site to help troubleshoot your issues.