Exchange 2013 Migration Outlook Anywhere Proxy Issues
One of the common problems I have come across when helping clients to migrate from Exchange 2007/2010 to Exchange 2013 is that while in Exchange 2013 coexistence RPC proxy doesn’t work. Sometimes these problems aren’t immediately apparent, some of the symptoms don’t become apparent until you migrate a mailbox back to your legacy Exchange 2007 or Exchange 2010 server. Problems may manifest as Outlook repeatedly prompting for credentials, users unable to access mailboxes, connectivity issues when accessing legacy public folders or users unable to access shared mailboxes and calendars.
With Exchange 2007 and Exchange 2010 Outlook clients connect via MAPI by default. With Exchange 2013 Outlook clients can only connect via RPC over HTTPS or Outlook Anywhere. When in Exchange 2013 coexistence connectivity to mailboxes on Exchange 2007 or Exchange 2010 servers is proxied via the Exchange 2013 server. In order for the HTTPS proxy to work successfully the authentication settings on both Exchange 2013 and the legacy Exchange 2010 or 2007 server must be identical.
So first things first we must check how both Exchange 2013 and Exchange 2007/2010 servers have Outlook Anywhere configured. To do that login to an Exchange 2013 server and execute the following command in Exchange Management Shell:
Get-OutlookAnywhere | fl servername,externalclientauthenticationmethod,internalclientauthenticationmethod,iisauthenticationmethods
This should output something that looks a bit like this:
So in this case the settings are identical, if your output looks like this then great things should be working (read on though if they aren’t as there is one more thing to check). However, if the settings differ from server to server in any way you need to take corrective action. You can go for different authentication methods but they must match on both servers. In my experience though these settings work best i.e. NTLM on both internal and external and for IIS. Other authentication methods such as basic can lead to a few bugs while in co-existence so unless you have a specific reason to configure this differently then I would advise that NTLM is the best choice for a trouble free coexistence.
To set Outlook Anywhere to the same on all servers you can execute the following Exchange Management Shell command:
Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM
Or you can set a server individually like this:
Set-OutlookAnywhere -Identity "EXCH1\rpc (Default Web Site)" -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM
At this point things should be working properly, however I have seen on a couple of occasions one more area that can cause some trouble. In IIS sometimes the Windows Authentication (NTLM) provider order can be mismatched between servers. To correct the provider order open Internet Information Services (IIS) Manager and click on the Rpc virtual directory. Next open authentication and you should see Windows Authentication is enabled. Click on Windows Authentication and then click on Providers… In the resulting window you can re-order the providers, you need to ensure the order is the same on all Client Access Servers.
Lastly whenever you make changes to the virtual directories you will need to perform an iisreset /noforce on each server to effect the changes immediately.
I find that misconfiguration of Outlook Anywhere accounts for most of the issue I see during Exchange 2013 coexistence so hopefully this helps some people out with their Exchange 2013 migrations.
**UPDATE** I recently came across another Outlook Anywhere / Autodiscover issue which could present with some similar symptoms. If the solutions above didn’t resolve for you and you are using a wildcard certificate then take a look at this.