With Exchange 2003 end of support on the horizon (April, 2014) and Exchange 2013 migrations hitting full stride, those of us in the trenches are beginning to experience the road bumps that are encountered when performing an Exchange 2013 migration from Exchange 2007/2010. (There is no direct migration path from Exchange 2003 to Exchange 2013).
One of the architectural changes in Exchange 2013 is the way Outlook clients connect to Exchange. Gone is RPC over TCP connectivity that has existed since the early days of Exchange. In its place is RPC over HTTP, more commonly known as Outlook Anywhere. As Exchange administrators know, Outlook Anywhere in the past was used by Outlook to connect to Exchange from outside the office without the need for a VPN. This was an optional protocol that was disabled by default. With Exchange 2013, all Outlook connectivity uses this mechanism both for internal and external connectivity. As such, it is enabled by default. (Of course, Outlook Anywhere does not need to be enabled for external access for those who consider it to be a security issue). With this change come additional attributes for Outlook Anywhere that allow for specific settings that are used to define internal connectivity. The legacy versions of Exchange (2007 and 2010) only had attributes for external Outlook Anywhere settings.
This change presents a potential stumbling block during a migration if one is not paying attention to configuration settings: the dreaded users being constantly prompted for credentials in Outlook. Most of us who have been working with Exchange have experienced this at one time or another – and there are a host of things that can cause this. This can rear its ugly head after a user has been migrated to Exchange 2013 under two circumstances:
- Connecting to Public Folders
- Opening shared mailboxes or calendars where the other mailbox resides on a legacy version of Exchange
When this happens, if the users click cancel they can access their mailbox. However, if they try to access a public folder or a shared mailbox/calendar they will be unable to do so.
[caption id="attachment_5085" align="aligncenter" width="300"] Click to enlarge[/caption]
The issue is triggered when the setting for Logon network security in the Outlook Profile is set to Anonymous Authentication.
This setting cannot be manually changed because Autodiscover will change it back. The cause of this is the configuration settings of Outlook Anywhere. If Outlook Anywhere is configured in the following ways, Autodiscover will set Outlook with Anonymous Authentication:
- ExternalHostName has a value (in other words Outlook Anywhere is enabled for external use) and the ExteralClientAuthenticationMethod is set to Negotiate. To determine the Outlook Anywhere settings for the external values, type: Get-OutlookAnywhere –Server <Name of CAS Server> | fl *External*. See the screen shot below for an example of settings that will create this issue.
[caption id="attachment_5090" align="aligncenter" width="300"] Click to enlarge[/caption]
- InternalClientAuthenticationMethod is set to Negotiate and InternalClientRequireSSL is set to True. The Outlook Anywhere internal settings can be retrieved by typing: Get-OutlookAnywhere –Server <Name of CAS Server> | fl *Internal*.
[caption id="attachment_5089" align="aligncenter" width="300"] Click to enlarge[/caption]
The underlying issue is that the legacy versions of Exchange do not support Negotiate as an authentication method. As such, if an Exchange 2013 user attempts to connect to a resource on a legacy Exchange server (such as when accessing Public Folders or shared mailboxes/calendars), Outlook is configured in an unsupported state, which results in the constant password prompts. The fix is to reconfigure Outlook Anywhere:
- If Outlook Anywhere is configured for external access, change the authentication method to something other than Negotiate (I prefer NTLM). The command is as follows:Set-OutlookAnywhere -Identity "<Server>\RPC (Default Web Site)" -ExternalHostname "<external URL> " -ExternalClientAuthenticationMethod ntlm -ExternalClientsRequireSsl $trueNote: When configuring the ExternalHostname you must also specify the ExternalClientsRequireSSL setting. The example above is setting this to true, which is the preferred setting for security purposes.
[caption id="attachment_5088" align="aligncenter" width="300"] Click to enlarge[/caption]
- If the InternalClientAuthenticationMethod for Outlook Anywhere is set to negotiate and InternalRequire is set to true, the command to fix this is:Set-OutlookAnywhere -Identity "<Server>\RPC (Default Web Site)" -InternalClientAuthenticationMethod ntlm -InternalClientsRequireSsl $trueNote: Just like with External access, when changing the parameters for internal access, InternalClientsRequireSSL must also be set.
[caption id="attachment_5087" align="aligncenter" width="300"] Click to enlarge[/caption]
Remember that these settings need to be done on all CAS servers. Once these changes are made, AutoDiscover will update the Outlook profiles to use Negotiate Authentication.
[caption id="attachment_5086" align="aligncenter" width="300"] Click to enlarge[/caption]
With the introduction of Outlook Anywhere Internal Host settings, one might ask how those settings are reflected in the Exchange Proxy Settings dialogue box for the Outlook profile. The answer is that Outlook will always display the internal settings even if the client is connecting externally. If the settings are different, Outlook tries to connect using the internal settings first. If that fails, it switches to the external settings. The Connection Status (Press Ctrl and right click the Outlook icon in the notification area) will show which hostname Outlook is using to connect.
[caption id="attachment_5091" align="aligncenter" width="300"] Click to enlarge[/caption]