We recently encountered a strange Outlook Anywhere connectivity and authentication failure that stumped us for several days. After migrating from Exchange 2007 to Exchange 2013 atop a Hyper-V platform, any Outlook profile previously connected worked fine, but we could not get a new profile to authenticate successfully outside of the internal network, a situation that Exchange 2013 specifically addresses with its HTTPS encapsulation of RPC.
This Windows domain was migrated from of a Windows 2003 environment (begotten from a Windows 2000 domain) and has the construct of inside.domain.com, with the FQDN Internet domain construct of domain.com. This bit of info turned out to be key to the solution.
We’d start a fresh profile from Outlook or Mail from inside Control Panel and the Add Account wizard would issue a Windows Security authentication challenge with user@domain.com in the user field waiting for the password. We’d enter the password and get the challenge dialog again 2-3 times and then it would sit and spin at “Searching for user@domain.com settings” until it failed. We’d check Change Account Settings, click Next, select Exchange Server go through the manual process, but it was all for naught. No amount knocking on that door would let us connect to the Exchange server.
But let’s go back to the first sentence in the previous paragraph: “…the Add Account wizard would issue a Windows Security authentication challenge with user@domain.com in the user field waiting for the password”. I’ve always considered the UPN construct user@domain.com and the SAM account construct of domain/USER to be synonymous, assuming Active Directory is operating properly and domain servers are accessible. But we have a slightly different situation here; the domain name is of the form internal.domain.com. So the SAM construct is internal\user, not domain\user. After some noodling, we figured out there was some kind of discrimination over the internal domain credentials going on here. So when the Add Account wizard prompted for the password with the UPN information pre-entered, we needed to select “Use Another Account” and entered the username with the form internal/user and the password. The Add Account wizard immediately authenticated and connected… no muss, no fuss. Done. Problem solved.
Upon reflection, I certainly understand why internal\user works as it should, but I’m still a bit mystified that user@domain.com (as well as user@internal.domain.com) failed to authenticate. I think I’ll leave that to someone who knows the nitty-gritty of authentication better than I.
