Hello

We have the following environment:

One CAS/HT/Mailbox Exchange 2010 SP3 UR8v2 hosted at Site A with internet access.

Two Exchange 2013 CU7 , one CAS, one Mailbox located at Site B with independent internet access.

All users access OWA by the URL https://webmail.domain.com/owa

We want to configure OWA coexistence, so we changed the DNS entries in order that webmail points to the Exchange 2013 CAS Server and also published the Exchange 2013 server from site A, because an App Firewall resides only in this site.

When we try to access OWA with a user that is hosted in Exchange 2013, everything it's ok. The strange behavior is detailed below:

1. When we try to access OWA with a user hosted in Exchange 2010 from site A, OWA shows in blank

2. When we try to access OWA with a user hosted in Exchange 2010 from site B, OWA shows a HTTP 500 error.

3. When we try to access OWA with a user hosted in Exchange 2010 externally, OWA shows in blank

We verified all the settings, reviewed the IIS logs but couldn't find a clue to solve this issue.

Any experience or suggestion is welcome!

You need to configure the 2010 CAS servers with a "legacy namespace",  meaning you need to set your 2010 CAS external URL's to something different from your 2013 CAS servers.

What's happening when you try to login through a 2013 CAS server with a 2010 user is the 2013 CAS server is trying to redirect the login to the external URL of the 2010 server which is the same URL as the 2013 CAS server, so the redirection fails and you get the blank screen.

I think the HTTP 500 error occurs after a "redirection loop" where the CAS server processing the login is continually being redirected to the 2013 URL which is trying to redirect back to the same external URL.

Check out this blog:

http://blogs.technet.com/b/meamcs/archive/2013/07/25/part-3-step-by-step-exchange-2007-to-2013-migration.aspx

Hi Corey

Thanks for your reply.

Sorry, I forgot to mention we did the coexistence using the legacy namespace, according to:

http://blog.enowsoftware.com/solutions-engine/bid/156110/Exchange-2013-OWA-Coexistence-with-Exchange-2010

We are using a wildcard certificate. The error codes are the same.

The strange thing is that even internally, it doesn't work.

what happens if you go to the 2010 internal CAS server's OWA url. Https://casserver/owa

does it work just going to the internal servername?

Hi,

I noticed that both Exchange 2010 and Exchange 2013 are internet facing. I suppose that the Exchange 2010 is mail10.domain.com which the webmail.domain.com is pointed to Exchange 2013. If that is the case, what's the OWA configuration for your OWA 2010 and OWA 2013?

Please run the following command to check the OWA configuration:

Get-OWAVirtualDirectory | FL Identity,*Auth*,*URL*

I suggest we can set the following URLs for OWA:

Set-OwaVirtualDirectory -Identity "Exch10\OWA (Default Web Site)" -ExternalUrl https://mail10.domain.com/owa -InternalUrl https://mail10.domain.com/owa

Set-OwaVirtualDirectory -Identity "Exch13\OWA (Default Web Site)" -ExternalUrl https://webmail.domain.com/owa -InternalUrl https://webmail.domain.com/owa

Please do the similar settings for your ECP URLs, then restart IIS service by running IISReset from a command prompt window to apply the settings.

In this way, when the Exchange 2010 users access the OWA 2010 with https://webmail.domain.com/owa, the URL would be redirected to the https://mail10.domain.com/owa for accessing. For more information about the Client Connectivity in an Exchange 2013 Coexistence Environment, please notice the Orange user in the following article:

http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

Regards,

Hi Corey

If we want to access directly to the server name url, OWA loads just fine!.

Hi guys

Thank so much for all your guidance!.

We verified all the settings, I wanna let you know that everything is working ok now. The issue was because Require SSL was enabled in the Default Website on the Exchange 2010 server, according to the following kb:

https://support.microsoft.com/en-us/kb/2839692

Everything is working ok now.

Thanks again.

Never mind, you fixed it :)

• Edited by Corey Riley 11 hours 18 minutes ago