Hi guys,

At this moment, I have Exchange 2013 and Exchange 2007 coexisting.

I am publishing Exchange 2013 through UAG and Exchange 2007 with ISA. In 2013 everything is fine. In Exchange 2007, I have set up a legacy namespace, the name is also included in the certs, external DNS and all External URL's on this side.

Apart from having to log into various OWA interfaces for Exchange 2007 users that is pretty much fine too apart from Outlook Anywhere. While it works well for a 2013 user, a 2007 user has to login many times and then it fails.

I did some testing with ExRCA with a 2007 user, and get the error: "A Web exception occurred because an HTTP 302 - Redirect response"

Can anyone shed light on my problem?

Thanks!

The Exchange 2013 CAS should proxy for the Exchange 2007 server.  I suspect it's redirecting because your Exchange 2007 server has an external hostname set to something different than your Exchange 2013 Outlook Anywhere hostname.  On the Exchange 2007 server run Set-OutlookAnywhere with the ExternalHostName configured to be the Exchange 2013 CAS or load-balanced VIP name as appropriate.

Hi Ed,

Thanks a lot for your reply. some more information, just to confirm your suspicions and clarify your suggestions:

• Legacy ActiveSync works fine
• Legacy OWA  works fine, albeit after various redirects (this will probably be an authentication issue that I need to check, without breaking ECP!)
• My namespaces are exchange.mydomain.com in Exchange 2013, and I have a legacy.mydomain.com namespace which points in the External DNS to my ISA server, and is listed on the certificate

In 2007, all external URL's point to legacy.mydomain.com and my ISA listens on that FQDN. The only exception is OAB which has no external url set, and it seemed to be working ok before the coexistance.

In this situation, I should set which url in the properties of my CAS (Outlook Anywhere?

Thanks!

• Edited by johnny mango Monday, May 13, 2013 6:23 PM typos

Another update. This morning I changed the aforementioned Outlook Anywhere URL on the properties of my CAS to legacy.mydomain.com (it was exchange.mydomain.com) and restarted IIS.

I now get just warnings on ExRCA:

Testing SSL mutual authentication with the RPC proxy server.
  The test passed with some warnings encountered. Please expand the additional details.
  Tell me more about this issue and how to resolve it
 
Additional Details
  The certificate common name Exchange.mydomain.com doesn't match the mutual authentication string provided legacy.mydomain.com; however, a match was found in the subject alternative name extension.

However, I still can't connect to Outlook from the Internet.

Only the OWA URL needs to point to legacy.  All others can use the Exchange 2013 URL and Exchange 2013 should be able to proxy for it.

Oh, ok, I'll try that.

Right now I can get a user in 2013 connecting perfectly. Throughout the day I was performing tests, and existing 2007 users were connecting, and then suddenly claiming there were failures. Just now I was testing with a user I had migrated from 2007 to 2013, and he has problems occasionally, although ExRCA runs pretty much clear (just a few warnings).

However, Ill try what you suggest about the legacy URL and report back :)

Hi again,

I haven't decided to change the namespace to the 2013 namespace as things seem to be working on phones, for example, OWA works largely, and Outlook Anywhere occasionally works. Also ExRCA runs clean for Outlook Anywhere.

However, the lingering problem I have is that migrated users are sometimes repeatedly asked for their password, and also their authentication randomly changes in Outlook 2013 from Basic to NTLM. With NTLM is when they appear to be prompted repeatedly for their password.

Do you have any reference that mentions that the legacy namespace only applies to OWA? It's just I am reticent to change it in case it upsets the delicate balance I have already established. This issue is preventing me from migrating more users.

Thanks!

John

That will happen if services redirect, which is one reason you should allow Exchange 2013 to proxy.

http://blogs.technet.com/b/exchange/archive/2013/01/25/exchange-2013-client-access-server-role.aspx

Hi again,

Thanks for your help Ed, I tried what you suggested but I started getting reports about ActiveSync issues and the problem wasn't solved.

We opened a support case, and it turned out it was a know issue related to Public Folders and users migrated from Exchange 2007 to 2013. Fingers crossed this is the resolution.

Thanks.

John

• Marked as answer by wendy_liuMicrosoft contingent staff, Moderator Monday, May 20, 2013 6:55 AM

hello Johnny

could you elaborate on this know issue with public folders ?

is there a Kb article or something ?

thanks in advance

neil

Hi Neil,

No kb article yet, as far as I'm aware.

Basically in Adsiedit, you need to go into Configuration, Services, Microsoft Exchange, Name of your organization, Administrative Groups, Name of your Admin Group, Databases and check the properties of each 2013 mailbox database.

You are looking for a property called msExchHomePublicMDB. In my case this pointed to a 2007 mailbox server, and clicking clear to remove the property apparently has done the trick.

Just be very careful and verify that this also applies in your case (I'm not making myself responsible ;) ). Perhaps backup your Schema Master.

Good luck!

this is strange solution man for the issue you had :)

Going to re-open an old thread.

The solution that Johhny got from MS is reliant on the fact that he had moved his public Folders to 2013. Don't do this if they are still on 2007 or you will break Public Folders

Does anyone have any update on this?

We are currently in same boat, I have a 2007 user thats been migrated to 2013 and having continual password prompts, when looking at connection state (internal not using external) it only prompts for password when trying to connect to public folders, Exchange 2013 user don't see Public Folders as they are all on Legacy servers, I am also in the same boat we have NOT moved Public Folders yet and are hesitant till we know this resolves this issue as we can't afford to do this to our customers.