We are in the process of migrating from Exchange 2010 to Exchange 2013 and we publish Exchange services to the Internet via TMG 2010.

The issue we are having is this:  When trying to set up an Outlook Profile using AutoDiscover it fails if the users mailbox is on the 2013 mailbox server.  If the users mailbox is still on the 2010 mailbox server Outlook configures on its own with no issues.  The Microsoft Remote Connectivity Analyzer shows no erros and connectes successfully every time with connectivity all the way to loggin in to the users mailbox no matter which backend the mailbox is on.  All other services are working fine with the new 2013 CAS connecting through to the 2010 backend.

I have a ticket open with Microsoft and after two full days on the phone they are unable to tell me what the problem is.  Im hoping someone here may have an idea.

I'm going to assume that since you mention TMG this is happening to users external to your environment.  What does autodiscover.domain.com resolve/NAT to?  IS it 2013? or is it 2010?  More than likely I think its going to be 2010 but it needs to be 2013.

If my assumption is wrong and this is internal, check your AutodiscoverInternalServiceUri and make sure they are all the same and point to 2013.  Another thing to check is to run Get-CASMailbox <user> | fl *mapi* and make sure that MAPIBlockOutlookRpcHttp is set to false.

Sorry for leaving that part out of the initial description.

Yes the problem is only happening to external users.  All of the TMG rules that were pointing to the 2010 CAS were modified to point to the 2013 CAS.  So autodiscover.domain.com and mail.domain.com now pass to the new CAS.

After running the Get-CASMailbox command on a test user with the mailbox residing on the 2013 backend, it returns MAPI Enabled: True, MAPIBlockOutlookNonCachedMode: False, and MAPIBlockOutlookRpcHttp:False

Hi a,

Thank you for your question.

By your state, we know that the user on Exchange 2013  could open outlook in internal, but they could not open outlook in external, right?

If that, I think the issue maybe occur on TMG cache, we suggest you delete Window user profile and make sure point to Exchange 2013. Then check if the issue persist.

In addition, you could post error that Exchange 2013 user account open outlook in external to us for troubleshooting.

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

I created a new test user account with a mailbox on the 2013 server.
Same result: Internal Outlook client connects no problem, External client keeps prompting for credentials.
If I manually configure External Outlook client it works.

I do see one error getting logged on the 2013 CAS in the RpcHttp log.

Client=ACTIVEMONITORING;......AuthType=NTLM;.....Status=401.1.Unauthorized;......HttpVerb=RPC_IN_DATA

Have you tried connecting to the 2013 mailbox/autodiscover using the Exchange Connectivity Analyzer?  https://testconnectivity.microsoft.com/

Maybe this will add to the HTTP Status message that you received and might point you in a new direction.  Just a thought.

Have you tried connecting to the 2013 mailbox/autodiscover using the Exchange Connectivity Analyzer?  https://testconnectivity.microsoft.com/

Maybe this will add to the HTTP Status message that you received and might point you in a new direction.  Just a thought.

As per my original post, I've tried the Exchange Connectivity Analyzer and it connects to my server every time with no errors.  It's only the Outlook clients that won't connect to 2013 mailboxes automatically...  When Outlook clients are configured manually they work, they just wont use autodiscover to connect properly to 2013.  They will, however, connect to a 2010 mailbox user using autodiscover.  I really feel like this is a TMG2010 issue because on the internal network there are no problems at all.  Its almost like TMG is stripping out something needed for the 2013 CAS to talk to the 2013 backend but allows whatever is needed for the 2013 frontend to talk to the 2010 backend.

I am sorry that I missed that detail from your original post.  Which tests did you run using the Connectivity Analyzer? Outlook and Autodiscover?  Also, have a look at this post.  https://social.technet.microsoft.com/Forums/exchange/en-US/2917587b-e525-4ead-9776-801b1574b210/exchange-2013-autodiscoveroutlook-anywhere

Make sure you went through this blog and you have everything setup correctly.

http://blogs.technet.com/b/exchange/archive/2012/11/21/publishing-exchange-server-2013-using-tmg.aspx

Any issues with OWA or EAS connectivity?

In the connectivity analyzer I've run both tests and they pass, all green check marks.

OWA, EAS connectivity is fine no matter if the users mailbox is still on 2010 or moved to 2013.

I've followed the Technet blog for publishing Exchange 2013 through TMG and the only difference to our existing configuration for the previous 2010 CAS was the addition of the Exchange 2013 GUID rule for OWA apps and the new OWA logoff URL.  

No blogs that I could find address the problem I'm having, it seems like its just supposed to work.  Everytihng I've found deals with a 2013 CAS not able to proxy to a 2010 backend which works fine for me.

OWA, IMAP, SMTP, POP, and Active-Sync all work with no issues no matter which backend mailbox server the users mailbox is on.  Outlook will work fine if you go in and manually add the profile or if the users mailbox is on the 2010 mailbox server.  The only thing that doesn't work is Outlook Autodiscover IF the users mailbox is on the 2013 mailbox server.  I've tried with Outlook 2010, Outlook 2013, and even the new Outlook 2016 beta.  I've checked to make sure that the versions of Outlook were supported and they were up to spec.

• Edited by a443434 18 hours 6 minutes ago

In the connectivity analyzer I've run both tests and they pass, all green check marks.

OWA, EAS connectivity is fine no matter if the users mailbox is still on 2010 or moved to 2013.

I've followed the Technet blog for publishing Exchange 2013 through TMG and the only difference to our existing configuration for the previous 2010 CAS was the addition of the Exchange 2013 GUID rule for OWA apps and the new OWA logoff URL.  

No blogs that I could find address the problem I'm having, it seems like its just supposed to work.  Everytihng I've found deals with a 2013 CAS not able to proxy to a 2010 backend which works fine for me.

OWA, IMAP, SMTP, POP, and Active-Sync all work with no issues no matter which backend mailbox server the users mailbox is on.  Outlook will work fine if you go in and manually add the profile or if the users mailbox is on the 2010 mailbox server.  The only thing that doesn't work is Outlook Autodiscover IF the users mailbox is on the 2013 mailbox server.  I've tried with Outlook 2010, Outlook 2013, and even the new Outlook 2016 beta.  I've checked to make sure that the versions of Outlook were supported and they were up to spec.

• Edited by a443434 Tuesday, July 28, 2015 1:23 PM

Hi a443434,

Thank you for your question.

We could run the following command to make sure you have configured all external URL on Exchange 2013:

Get-AutodiscoverVirtualDirectory -server <ExchangeServerName> | fl InternalUrl,ExternalUrl

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

Jim

It feels like something is not getting passed properly through TMG.  The best way to verify this would be to route around TMG externally (change firewall NAT rules) and see what happens.  If everything works properly then you know (eventhough we know everything seems to work internally properly) the problem is with TMG and not Exchange and maybe you can push Microsoft support to escalate the call internally for an answer.  Sorry I can't be of more help, I don't deploy TMG so I don't have the experienc

a443434,Thank you for the update!  As long as you have the same UCC certificate installed on both the TMG server and Exchange CAS then I would start looking through the TMG logs when trying to connect via Outlook.  I would start a capture and try connecting to see what shows up.  If TMG is having issues passing authentication or connections through to Exchange when connecting through Outlook then it should be logging that information.