Outlook 2016 has a profile creation changes we know about. Specifically, manual profile creation for an Exchange mailbox is no longer available. You must use Auto Discover to create the profile. All previous versions of Outlook using Auto Discover (2007, 2010, and 2013) had manual profile creation as an option if Auto Discover failed. There seems to be another change we weren’t told about.
Testing with ‘Fiddler’ shows that these previous versions authenticated with the User Principal Name (UPN) and if this failed, they attempted to use the credentials the user was logged on with. On a workstation or Terminal Server (Citrix) session, these were the domain credentials (assuming the workstation was a domain member). Outlook 2016 appears to simply never take the second step.
Why does this matter? Two issues. 1) Auto Discover requires authentication to be successful, and 2) if the mailbox is a ‘linked mailbox’ in on-premises Exchange, the logged on credentials are usually required because the UPN will reference the disabled mailbox object in the ‘Resource Forest’ which cannot be logged on to, leaving the user in an endless UPN logon loop. This is especially true if conventions like ‘EMail, UPN, and SIP should all match’ are followed.
So, for most situations, Outlook 2016 profile creation just works. But, for a linked, on-premises mailbox, it likely requires user intervention to change the logon manually to the ‘domain\samAccountName’ of the user to create the profile. Remember, there is no longer a manual alternative.
Worse, the old process was transparent: no user intervention, no prompts, the mailbox just opened. Now, the user is involved and needs instruction to get past the issue.
Does Microsoft know about the issue? Yes, I have a client that has reported it but they have no fix as of this writing.
Are there workarounds beyond sticking with an older Outlook version? Yes, you can use the registry value described in this update. Additionally there are a couple of more. As above, instruct the users to change the login user and supply domain credentials. Or, one can use UPN Suffix routing, at the forest level, to force the login to the ‘Account Forest’ by routing that name space on the trust. Neither is ideal. The first for obvious reasons. The second because it forces ALL logins for that UPN Suffix to the ‘Account Forest’ and that may fix this issue and create others. There are also a finite maximum number of UPN Suffix’s that can be routed. Some references say 800 others 1200. For a hosting company this could also an issue.
What has our testing shown? There are no differences across Exchange 2010, 2013, 2016. None of the ADAL, modern authentication, or O365 registry values seem to help. The OS of the Workstation seems to make no difference. Windows 7 – Windows 10 to version 1803 are the same.