Hi

Setup:

Exchange 2007 On Prem. Exchange 2013 CU2 Hybrid server (both CAS and Mailbox roles on 1 server). Office 365 setup ok. Dirsync and ADFS working ok. Few users migrated from on-prem to O365. Mail flow working OK.

The problem is this - as soon as an on prem user is migrated to O365, their autodiscover stops working against the 2013 Hybrid server. It now comes up with an HTTP Error 500. Running the testexchangeconnectivity tool returns a status of "OrganizationMailboxNotFound"

However - autodiscover for the same user against the 2013 Server on Port 444 (ie the Mailbox role) works perfectly. Copying the contents of the autodiscover folder from the MBX Clientaccess folder to the CAS Httpproxy folder then results in testexchangeconnectivity working perfectly again.

It is almost as if the 2013 CAS is not proxying the requests correctly for users with Office 365 mailboxes. On prem users work ok.

Any thoughts or ideas much appreciated.

Thanks for looking

Autodiscover shut point to O365. Outlook users internal use SCP point first then  auto discover url.

Use CNAME internally autodiscover -> autodiscover.outlook.com

If you test  autodiscover connectivity with Outlook client (Test E-mail AutoConfiguration), does ist shows correct url. Try to connect to that urel with effected user.

And be aware, that you should wait dirsync so mailbox so on premises and cloud setting are up to date 

Autodiscover shut point to O365. Outlook users internal use SCP point first then  auto discover url.

Use CNAME internally autodiscover -> autodiscover.outlook.com

If you test  autodiscover connectivity with Outlook client (Test E-mail AutoConfiguration), does ist shows correct url. Try to connect to that urel with effected user.

And be aware, that you should wait dirsync so mailbox so on premises and cloud setting are up to date 

• Proposed as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, July 16, 2013 10:08 AM
• Unproposed as answer by Manic_Miner Tuesday, July 16, 2013 3:57 PM

Hi MaliStane - thank you for your reply. I have set the internal DNS CNAME as you suggested.

Internally, Outlook works ok. It works its way through the SCPs with 500 errors, then hits the DNS entry and gets redirected out OK.

Externally from the testexchangeconnectivity site, Autodiscover fails with the 500 error (code below)

An HTTP 500 response was returned from Unknown.
Headers received:
Connection: Keep-Alive
request-id: 178bd09a-8018-4518-be6a-0d65ce036bce
X-CasErrorCode: OrganizationMailboxNotFound
Persistent-Auth: true
X-FEServer: (NAMEOF2013CASSERVER)
Content-Length: 0
Cache-Control: private
Date: Tue, 16 Jul 2013 14:44:16 GMT
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET

The problem seems to be that the 2013 server is not returning the redirection. If I now copy the contents of the port 444 Backend autodiscover to the port 443 CAS autodiscover, it will work perfectly, but surely this can't be right. Its like the authentication is seeing that the user has an O365 mailbox and not passing the request to the Backend, which seems to deal with it correctly.

Just for clarification - this is only for users whose mailboxes have been migrated to O365. On prem users - autodiscover works perfectly internally and externally.

Thanks for your help so far.

Wait, that's incorrect.  I know this is an old thread, but I wanted to correct this information in case others came and found it.

In a hybrid configuration, unless you are entirely migrated to the cloud, autodiscover must point to the on-premises Exchange 2013 CAS(es).  Office 365 has no real knowledge of the on-premises environment, thus cannot provide any information for services and mailboxes that still remain on-premise.  The on-premises autodiscover obviously knows about the on-premises mailboxes and services, but also can provide the redirection to Office 365 for mailboxes that were migrated there.

It sounds like the migrated user account is missing the proper TargetAddress attribute..... When you migrate a user, Exchange on-premises should convert the user object on-premises to a mail-user and set the TargetAddress attribute (RemoteRoutingAddress) on the AD account. The TargetAddress is what tells autodiscover and mail-flow where the new mailbox is located, it's what initiates the autodiscover redirect.