The Problem
In the latest updates and versions of Microsoft Office 2016, I found a bug where when a user adds a new on-premise Microsoft Exchange 2016 account, it will repeatedly prompt for a username and password and ultimately fail if you hit cancel (no matter how many times you enter credentials). This was on the internal LAN on a domain joined workstation.
I did the usual checks:
- Check Virtualdirectory configuration on Exchange
- Check Virtualdirectory configuration on IIS (Internet Information Services)
- Check Autodiscover DNS entries, InternalURL and ExternalURL configuration
- Check for SCP inside of domain
All the of the above came back fine and were configured properly.
I have numerous other Outlook 2016 clients configured and working (installed as older versions, but have been updated), so I used those to troubleshoot (same scenario, domain joined on internal LAN and external WAN). After spending 10 hours ripping apart everything, confirming configuration, I noticed that when using the “Test Email Autoconfiguration…” (holding CTRL while right clicking on Outlook tray icon), that the e-mail clients had a skewed order for checking autodiscovery.
The e-mail clients were actually trying to authenticate with Office365 before my own on-premise Exchange Server (domain SCP or autodiscover records). This is absolutely bizarre! After spending 2 hours googling (I couldn’t find anything), I finally stumbled across this document and found an interesting piece of information:
https://support.microsoft.com/en-ca/help/3211279/outlook-2016-implementation-of-autodiscover
“Outlook uses a set of heuristics to determine whether the user account provided comes from Office 365. If Outlook determines confidently that you are an O365 user, a try is made to retrieve the Autodiscover payload from the known O365 endpoints (typically https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml or https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). If this step does not retrieve a payload, Outlook moves to step 5.”
WTF?!?!?
So while this doesn’t explain why this happened, it explains what’s happening. I believe this is what’s happening as my working clients are trying to Autodisocver with Office365 first…
I went ahead an created a registry value to control the policy for “ExcludeExplicitO365Endpoint“. After configuring the registry key, I noticed that Autodiscover was now functioning properly and checking SCP and autodiscover DNS records first. I have no idea why the “heuristics” determined I was an Office365 user, but I’m not (I do have access to Office365 as a partner, but don’t use it and don’t have it configured). This may effect other partners, or users that utilize some O365 services…
The Fix
To fix this issue, create a text file and copy/paste this text below.
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover] "ExcludeExplicitO365Endpoint"=dword:00000001
Then save it, and rename it as ExcludeExplicitO365Endpoint.reg and run it (this will import the applicable registry key). ONLY DO THIS if you are using an Exchange On-Premise account, and not a Office365 or hosted exchange account.
Keep in mind that autodiscover also queries the domain root (domain.com), before querying the autodiscover host (autodiscover.domain.com). If you want to stop both the Office365 autodiscover and the root domain autodiscover challenge, use the following below:
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover] "ExcludeExplicitO365Endpoint"=dword:00000001 "ExcludeHttpsRootDomain"=dword:00000001
You’ll notice that we also set “ExcludeHttpsRootDomain” to “1” which stops it from checking the root domain.
After this, the issue was completely fixed. If you know what you’re doing, you can also use Outlook GPO settings and deploy this to a vast number of systems using Group Policy.
Additional Note (added November 2nd, 2018)
While reading numerous documents covering autodiscovery, I also came across an article that went in to detail with particulars as to how Mapi over HTTP functions. Even with the above, when accessing Outlook externall from the domain, you may still notice a single password prompt for the first time you log in externally.
After reading through documentation, I found that this is most likely because the first user account login (the very first time the user logged in on the computer), the username format of “DOMAIN\Username” was used, and not the UPN. The documentation mentioned that this may fail the negotiation, which will require a single password prompt on autodiscovery. This issue can be avoided by using the users UPN ([email protected]) to log in for the first time on the system.
Please note that the UPN must match the user’s e-mail address.
[…] This is due to the autodiscover order being skewed on a new Outlook 2016 update. Please see https://www.stephenwagner.com/2018/01/14/cannot-create-exchange-2016-account-office-2016-due-repeate… for more information and a fix for […]
Thanks for the info. I too wasted a load of time on this one.
Stumbled over this today. Unfortunately ExcludeExplicitO365Endpoint=1 did not work. I ended up with setting a local split DNS domain zone “outlook.office365.com” on the local DNS server and pointed the root A-Record of this zone to the internal on-premise Exchange 2016 Server. The password prompt in Outlook 2016 then disappeared.
Hi PJames,
After setting the registry, did you restart the system?
Also, when creating the REG file, did you copy/paste exactly?
I’ve resolved this issue on many systems with this solution, it should work.
Cheers,
Stephen
Thank you for posting this. It resolve our issue with Outlook 2016 with the latest version..
I use Win10/Outlook 2016 with a hosted Exchange account thru Network Solutions. I recently came back from vacation and found Outlook would not run with an “Your Mailbox has been Temporarily moved…” error. I tried to make a new profile and could not. I tried your registry fix and all is well now! Thanks so much. Network Solutions knew of the problem but would only tell me to talk to Microsoft and would not offer a solution or point to a reliable source to fix this problem.
…one more comment
I also deleted the .xml under outlook//16 which had the O365 Autodiscovery
Hi,
we just have a similiar problem with one client win 10 and new Office 365 installation, no more updates and impossible to create a connection to our cloud exchange server. All other clients are working fine, configuring the same mailbox on other PCs with no problems. We just checked for hours on the www but didnt find anything.
You think your solution works also fine with our cloud exchange from our provider?
Thanks in advance,
RB
Hi Roland,
It sounds like this very well could be what is causing your issue. If you try the actions in this blog post, they are easily reversible if it turns out that this isn’t what is causing your issue.
Let me know if this fixes it up for you!
Cheers,
Stephen
Anybody have a sample of the GP created for this? I assume we need to add the ADMX files for Office 2016 into the GP, but I’m having trouble finding the exact location and what entry to make. Any help is much appreciated.
Hello Stephen,
I agree; WTF!!!! We had a system that has worked fine for years. I use a hosted a exchange provider for my clients. Suddenly, I can no longer set up email boxes in outlook. Fortunately sherweb knew of the problem and gave me this solution. But now with my 100 hosted email clients, I will now have to deal with something that should not be a problem and wasn’t until recently. It is these kinds of self inflicted gunshot wounds that make me consider leaving this business. Thanks for a clear, insightful post.
Cheers,
ric
hahahaha, thanks ms for 3 hours of googling..
thanks stephen, cheers
Well, it’s 2019 and this problem still affects newer versions of Outlook 2016. The registry fix has worked for me in the last 8 PC deployments we made. However, it’s a real pain to hack the registry for every user.
Here is a slant on the same issue. I have recently moved to Office365 and migrated our 2014 exchange server to 365. This worked perfectly and we’ve updated all desktops to the Office365 Apps. Recently, our business was merged with another using an On-premise exchange. We cannot connect outllook to their exchange, even with the registry changes where the Office365 email account is the same as the one we want in the new on-premise server.
Thank you. This saved a lot of time.
Ohh my god.. I’ve been beating my head against the wall trying to work these bugs out with a Office 2019 deployment. I was baffled to why a Microsoft Modern Authentication password challenge kept coming up every time we would open Outlook with an onprem Exchange deployment . I have wasted sooo much time.. Thank you so much for ending my witch hunt
Thank you so much! Now i have to get somebody in here to fix the sheetrock where i’ve been banging my head on this problem. It so felt like an autodiscover problem, but everything checked out fine so it was driving me nuts. Great heuristics, Microsoft.
Thanks so much, this was a nightmare for us
PJames: “I ended up with setting a local split DNS domain zone “outlook.office365.com” on the local DNS server”
What a find! This was the trick that did it for me (combined with the registry keys).
The latest Office 365 update (version 13029.20344 from August 11, 2020) somehow keeps insisting on connecting to Microsoft servers if you have a Microsoft account registered with the same email address (but no Microsoft 365 mailbox associated with it). The registry keys alone allowed me to configure a fresh Outlook profile but within minutes Outlook would reconfigure the profile towards MS servers. Only after adding a hosts file pointing outlook.office365.com to the IP of our Exchange 2019 servers does the autodiscover service in Outlook keep the profile pointing to our servers and not MS servers.
Incredible this is necessary! What’s the point of autodiscovery then when they automatically assume MS servers priority above anything else?…
One Note… changing the provider details (removing Negotiate) does not need an IIS reset, so make sure you make this change after hours, or users who are authenticated with kerberos will see pop-ups and have to restart Outlook, and maybe even restart their machines.
Hello,
,, Please note that the UPN must match the user’s e-mail address.”
Our users have different primary smtp address, but they have alias in upn format, is it still ok?
Thanks
Hi Jerry,
For autodiscover to function properly, the UPN should match their primary SMTP address. Anything else may cause repeated password prompts.
Cheers,
Stephen