Almost all issues related to Exchange Connectivity or usability all come down to relating to Autodiscover and its properties.
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, 2013, 2016, or 2019. 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.
Make a Backup of Your Environment Configuration
First thing is first, make a backup of your environment’s configuration. Run the following commands in Exchange Management Shell to backup your configuration. Don’t forget to change the RESOLVE-DNSNAME commands at the bottom so that they reflect your current OWA URL hostname and the Autodiscover record for your external domain name. The Start-Transcript/Stop-Transcript lines will output all of this to a text file in the current folder, as well as on screen.
Start-Transcript EnvironmentBackup.txt Get-OutlookProvider | Format-List Get-OutlookAnywhere | Format-List Get-ClientAccessServer | Format-List Get-ActiveSyncVirtualDirectory | Format-List Get-AutodiscoverVirtualDirectory | Format-List Get-EcpVirtualDirectory | Format-List Get-OabVirtualDirectory | Format-List Get-OwaVirtualDirectory | Format-List Get-MapiVirtualDirectory | Format-List Get-PowerShellVirtualDirectory | Format-List Get-WebServicesVirtualDirectory | Format-List Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Format-List Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Get-ADPermission | Where-Object { $_.extendedrights -like '*routing*' } | fl identity, user, *rights Resolve-DnsName -Type A -Name mail.domain.com Resolve-DnsName -Type A -Name autodiscover.domain.com Resolve-DnsName -Type A -Name mail.domain.com -Server 8.8.8.8 Resolve-DnsName -Type A -Name autodiscover.domain.com -Server 8.8.8.8 Resolve-DnsName -Type MX -Name domain.com -Server 8.8.8.8 Resolve-DnsName -Type TXT -Name domain.com -Server 8.8.8.8 Resolve-DnsName -Type A -Name i-should-not-exist.domain.com -Server 8.8.8.8 Stop-Transcript
NOTE: If you get errors on the Resolve-DnsName commands, please use the following NSLookup Commands instead.
nslookup -type=a mail.domain.com nslookup -type=a autodiscover.domain.com nslookup -type=a mail.domain.com 8.8.8.8 nslookup -type=a autodiscover.domain.com 8.8.8.8 nslookup -type=mx domain.com 8.8.8.8 nslookup -type=txt domain.com 8.8.8.8 nslookup -type=a i-should-not-exist.domain.com 8.8.8.8
Now that we have an Environment Backup, let’s proceed with the steps to fix your environment.
DNS – Always the First Step
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, review the Environment Backup – The 7 Resolve-DnsName commands at the end.
The first 2 Resolve-DnsName commands should both respond from an internal computer to the internal IP of your Exchange server (eg. 192.168.1.55).
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).
The next 2 Resolve-DnsName commands should both respond externally (Via Google’s DNS) to your external IP of the mail server (eg. 38.55.11.55).
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 external DNS Manager create an A record for autodiscover.domain.com and point it to the external IP of your mail server (eg. 38.55.11.55).
The 5th Resolve-DnsName command will show you your MX records on the internet. MX Records should NOT point to an IP Address as stated in RFC1035 (https://tools.ietf.org/html/rfc1035#section-3.3.9). They should have a priority at the beginning where the lowest number is the preference. If you are directing inbound mail traffic to an Anti-Spam 3rd party provider, this will be the hostname(s) associated with them. In the case of an onsite appliance, create a new A record called inbound.domain.com and give it the IP for your Anti-Spam Appliance, and then set the MX Records to 10 inbound.domain.com.
The 6th Resolve-DnsName command will show you your TXT records – these records are used for extra information in DNS, and one of the extra pieces of information you should have in there is an SPF record. A Sender Policy Framework (SPF) record identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to prevent spammers from sending messages with forged From addresses at your domain. If your domain does not have an SPF record, some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorized mail server. You should use an SPF Generator to get the proper syntax for your SPF Record (https://www.google.ca/search?q=SPF+Generator).
And the 7th Resolve-DnsName command should respond that this record does NOT EXIST. If it does resolve to an IP, there is likely a wildcard record on your domain (*.domain.com) that is pointing to your webserver. Some webhosting companies do this for subdomain management instead of putting an explicit hostname in their DNS records. It actually causes more problems than it fixes, so where possible, you should log into your domain’s external DNS Manager and remove the wildcard record.
Configure Your Exchange Virtual Directories
After Split-DNS is confirmed working, the next things to check and fix are the Virtual Directories and the Client Access Server Autodiscover URI. 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). You should always use NTLM over Basic authentication as Basic sends the username and password in the clear, and NTLM doesn’t as it is Windows Authentication. On Exchange 2013+, you also have a new option called Negotiate, which is recommended, but if you have Outlook 2010 and Outlook 2007 clients, keep it with NTLM for backwards compatibility. For futureproofing, please also turn on SSLOffloading for OutlookAnywhere which is enabled by default on Exchange 2013+ (https://technet.microsoft.com/en-ca/library/dn635115(v=exchg.150).aspx#OA).
For Exchange 2007/2010
Set-OutlookAnywhere -Identity 'SERVER\Rpc (Default Web Site)' -SSLOffloading $true -ClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM
For Exchange 2013+ with backwards compatibility with Outlook 2010 and 2007
Set-OutlookAnywhere -Identity 'SERVER\Rpc (Default Web Site)' -SSLOffloading $true -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM,Negotiate
For Exchange 2013+ with Outlook 2013+
Set-OutlookAnywhere -Identity 'SERVER\Rpc (Default Web Site)' -SSLOffloading $true -ExternalClientAuthenticationMethod Negotiate -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Basic,NTLM,Negotiate
Now that we’ve got OutlookAnywhere configured, let’s configure the OutlookProvider settings. By default three Outlook Providers are used to configure settings individually for Exchange RPC protocol or internal clients (EXCH), Outlook Anywhere (EXPR) and WEB.
The EXCH setting references the Exchange RPC protocol that is used internally. This setting includes port settings and the internal URLs for the Exchange services that you have enabled.
The EXPR setting references the Exchange HTTP protocol that is used by Outlook Anywhere. This setting includes the external URLs for the Exchange services that you have enabled, which are used by clients that access Exchange from the Internet.
The WEB setting contains the best URL for Outlook Web Access for the user to use. This setting is not in use.
To harden security, it is best practice to set the CertPrincipalName for each of the Outlook Providers (it is also required if you have any lingering XP Clients that will use Outlook). This will make sure that only a certificate with a specific subject name will be accepted.
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 Client Access Server’s Autodiscover record to the OWA Hostname:
Set-ClientAccessServer -Identity 'SERVER' -AutoDiscoverServiceInternalUri 'https://OWAHOSTNAME/Autodiscover/Autodiscover.xml'
Set all VirtualDirectories (VDs) to the OWA Hostname using HTTPS except for the AutodiscoverVirtualDirectory which gets set to blank ($null) for InternalURL and ExternalURL. We will also turn on -RequireSSL for the OWA VD. We also will set the InternalNLBBypassUrl to $null. For most this works fine, however if you are using multiple exchange servers in an NLB Cluster or crossing Active Directory sites, don’t set that to null. More information here: https://blogs.technet.microsoft.com/exchange/2008/07/18/ews-cas-to-cas-request-proxying/
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-AutodiscoverVirtualDirectory -Identity 'SERVER\Autodiscover (Default Web Site)' -InternalUrl $null -ExternalUrl $null Set-MapiVirtualDirectory -Identity 'SERVER\mapi (Default Web Site)' -InternalUrl 'https://OWAHOSTNAME/mapi' -ExternalUrl 'https://OWAHOSTNAME/mapi' 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
Set the FQDN option of all the enabled Send Connectors:
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Set-SendConnector -Fqdn OWAHOSTNAME
Restart IIS and the Microsoft Exchange Transport Services to make the changes take effect immediately. Exchange should be working now and all of your clients should have no problems connecting.
What Else Can I Do to Secure Exchange Better?
If you have ever examined an email message header, you would have noticed that it contains internal Exchange server FQDN information and IP addresses. This exposes the AD domain details of your network to the outside world. To prevent this information from escaping your network onto the Internet, you can use the Exchange header firewall to hide the internal server information. You do this by taking away the rights to send the internal details in a message header (ms-Exch-Send-Headers-Routing) on the send connector you use to send email on the internet.
Remove ms-Exch-Send-Headers-Routing rights on ALL Active Send Connectors:
Get-SendConnector | Where-Object {$_.Enabled -eq $true} | Remove-ADPermission -User 'Nt Authority\Anonymous Logon' -ExtendedRights 'ms-Exch-Send-Headers-Routing'
Remove ms-Exch-Send-Headers-Routing rights on specific Active Send Connectors:
Get-SendConnector -Identity CONNECTORNAME | Remove-ADPermission -User 'Nt Authority\Anonymous Logon' -ExtendedRights 'ms-Exch-Send-Headers-Routing'
Restart IIS and the Microsoft Exchange Transport Services to make the changes take effect immediately.
Hey, What About Outlook Web Access (OWA)? How to Make it Easily Accessible to Users:
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 the 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.
SSL Certificates – Why Can’t I Use a Self Signed Certificate?
You should NOT use a self-signed SSL certificate, not even for a lab. 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. If you don’t already have a proper 3rd party certificate, I would suggest taking the plunge for $29.88 USD – https://www.namecheap.com/security/ssl-certificates/comodo/positivessl-multi-domain.aspx – 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). If instead you want to spend the time looking for a free option instead, try using LetsEncrypt which will take longer for you to setup and manage, but will cost nothing but your time (it is up to you whether your time is worth more or less than $29.88 USD)
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.
OK, I Got All of That. What About Troubleshooting?
For Exchange troubleshooting issues with autodiscover and connectivity issues you can use Microsoft’s TestConnectivity site.
https://testconnectivity.microsoft.com
Also, for unexpected Autodiscover behaviour, you may have to include or remove the following registry keys on the affected client computers:
[HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover] "PreferLocalXML"=dword:00000001 "ExcludeHttpRedirect"=dword:00000001 "ExcludeHttpsAutoDiscoverDomain"=dword:00000001 "ExcludeHttpsRootDomain"=dword:00000001 "ExcludeScpLookup"=dword:00000001 "ExcludeSrvRecord"=dword:00000001 "ExcludeLastKnownGoodURL"=dword:00000001 "ExcludeExplicitO365Endpoint"=dword:00000001
