We've been running Outlook 2010 for several years, but I'm beginning to test Outlook 2016 against our on-premises Exchange 2010 server. The short version - connection works perfectly in-office, but autodiscover works slowly when offsite.
My current config:. Office 2016 is deployed via MDT scripted install, Outlook customized via OCT to use ZeroConfigExchange. It works perfectly in-house.
A domain user who logs onto a workstation with Office 2016 deployed in this manner can open Outlook and is prompted for absolutely nothing. The profile is automatically and quickly connected without the user being asked for anything. Since Exchange 2010 doesn't support MAPI over HTTP, I'm deploying this registry key to all my workstations: HKCU Software Microsoft Exchange, create a DWORD entry with the name MapiHttpDisable, Value: 1. To cover all bases involving autodiscover redirection prompts, I've deployed the following registry entries to: HKCU Software Microsoft Office 16.0 Outlook AutoDiscover RedirectServers: autodiscover.publicdomain.com, remote.publicdomain.com, mail.publicdomain.com. Since our autodiscover.xml record is hosted at, I've deployed the following registry key on Outlook client workstations: HKCU Software Microsoft Office 16.0 Outlook AutoDiscover, REGDWORD ExcludeHttpsRootDomain, Value=1. At the:.
The Outlook Connectivity Test takes about 13 seconds and completes successfully. The Outlook Autodiscover Test takes about 3 seconds and completes successfully with warnings. The first warning is a general failure of autodiscover at our root domain 'publicdomain.com' since our autodiscover record is not hosted there. The second warning is: 'Analyzing the certificate chains for compatibility problems with versions of Windows. Potential compatibility problems were identified with some versions of Windows.The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update.
Your certificate may not be trusted on Windows if the 'Update Root Certificates' feature isn't enabled.' I've also used Outlook's 'Test E-mail AutoConfiguration' tool to troubleshoot the issue. I enter my email address, make sure the only option checked is 'Use AutoDiscover' and hit 'Test'.
Sep 12, 2016 Because it's a hosted Exchange server we use DNS SRV to point then to the autodiscover.xml file from our Exchange provider. The produced log file from Outlook 2016 for Mac is showing then the final step to resolve the settings via autodiscover, but to fail finally.
Windows immediately prompts me for a password for my email address. Our internal domain is different than our public domain, so I select the option to use another account, then type my domain username and password. The test then succeeds, and does so immediately. It does not take 90 seconds, or even a couple of seconds to succeed. Check your settings with my guide below.
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.
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. To confirm that Split-DNS is working correctly: From an internal computer. Text ping mail.domain.com ping autodiscover.domain.com These should resolve to your external IP of your mail server (eg. 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.
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. 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. 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. Thanks Overdrive for the quick and detailed response. More information from my side:. Split DNS has been correctly configured for years. I cannot ping my mail server externally because my firewall isn't passing ICMP, but it is reachable by clients.
My Exchange 2010 server is running on a SBS 2011 box. I'm using CNAME records for AutoDiscover instead of A records. I have seen both approaches mentioned, but I haven't seen anything definitive about which method Microsoft recommends/prefers. I also have a SRV autodiscover record configured in external (and internal) DNS, although from what I've read, the SRV record is the last method Outlook will try when all other methods have failed, so I don't know that it's actually coming into play in my scenario. I've always used NTLM authentication with RPC over HTTP, and with Exchange 2010 and Outlook 2010, it was all working correctly.
I'll look more closely into the Exchange and IIS configs. In your experience, would different permissions be required on the virtual directories for Outlook 2016 than what was required for Outlook 2010 clients? Also, pardon my asking, but.did you read my entire post before replying? Your reply came so quickly. Obviously it was pre-written, which is fine, but it's advising me to do many things that I've clearly stated that I've already done. Thanks again. Yes, I did read your message, hence my direct notes about registry edits and the fact that I've never used Office 2016.
What I can say, and what my guide helps with is confirming that all settings are proper. The only other thing that my guide doesn't have is if your external dns has a.domain.com record - remove it. It screws things up more times than it fixes things. You also mentioned mapi over http - are your VD's http or? Everything should be set to https as shown in my guide. The next thing to look at is firewall and anything else in between - is it a direct 1 to 1 nat mapping with port 80/443 allowed through? Is it a many to 1 nat mapping with 80/443 allowed and redirected to the exchange server's CAS?
Is there an appliance in between? Is there an ISA server or any other type of proxy server (bridged or not)? Thanks Overdrive, Sorry, my first reply went out before I saw your second reply with your notes specific to me. Thanks again for all the help.
Actually, your guide is exactly the sort of thing I'd love to have if I were setting up new Exchange organization from scratch. I looked around earlier for a detailed how-to for autodiscover configuration and would have loved to have yours.
To Rod, yes, iiuc, Exchange 2010 doesn't support MAPI over HTTP - that was first introduced in Exchange 2013. That's why the registry setting MapiHttpDisable is required on Outlook 2016 clients. It causes Outlook to fall back to RPC over HTTP without attempting a MAPI over HTTPS connection. And I'm specifically talking about Outlook 2016 clients using Outlook Anywhere - not EAS.
I have more interesting information though. I was testing this using my Internet connection at home. I just connected my laptop to the hotspot on my phone, and what do you know - Outlook connected with no delay over that connection. I then brought my laptop to our local office.
It has two Wi-Fi networks; one for domain users/equipment, and a guest Wi-Fi that is configured to use a separate, totally isolated VLAN that pipes users straight out to the Internet. When I connect to guest wi-fi and then open Outlook, it also connects almost immediately.
So it appears this issue is probably not due to a configuration issue with Exchange, DNS, or the Outlook 2016 client, but rather is a particular quirk of my home network. My hunch is that it has something to do with my firewall at home, which is a Cisco ASA5505. There's likely something going on with it - maybe a certain type of protocol inspection - that's causing the delay. I'll test on as many other foreign networks as I can to collect more data, and post back with the results.