Hi all,

I have installed Exchange 2016 and everything is working except autodiscover for Outlook 2013.When setup using active sync (mobile) it works fine.

When setup in Outlook (new profile) I enter Name,E-mail and password. Then click next and it prompt for username and password. I then get message I need to restart outlook for changes to take effect. When start Outlook I get error :

"The action cannot be completed. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action."

Both internal and external dns,the autodiscover record is correct and I can see in TMG that the request was forwardet to Exchange server.

Get-WebServicesVirtualDirectory  is showing correct info (internal and external) : https://mail.domain.com/EWS/Exchange.asmx and I can browse it fine

Get-clientaccessServer : https://mail.domain.com/Autodiscover/Autodiscover.xml is giving me error 600 code.

When run https://testconnectivity.microsoft.com the autodiscover url is showing domain.com instead of autodiscover.domain.com.

What am I missing?

Server has rebooted and error is on multiple computers (outside domain)

t

Hi,

Please can you let us know where your internal and external DNS records are pointing for the legacy server, outlook anywhere internal and external hostname and also for autodiscover. 

Have you also tried entering the server details in manually for the outlook connectivity checks on testexchangeconnectivity.com? This bypasses autodiscover and allows you to narrow down the causes.

Can you also test internally to work out whether the TMG is the problem? (I'm assuming you're only using the TMG for connections from the internet)

Mark

Hi Mark,all your question is already answered in my post.

Think main issue is why autodiscover.xml is pointing to wrong url. It is searching for domain.com instead of autodiscover.domain.com.

My outlook anywhere setting is set to mail.domain.com and also WebServicesVirtualDirectory and clientaccessServer.

Wondering if something has changed in Exchange 2016,since earlier I did not have this issue.

Ah, ok. I was after a little more detail but no problem.

The autodiscover client does not yet know what version of Exchange you are using when it tries to find the autodiscover.xml configuration. It proceeds in a particular order when trying to find the autodiscover.xml file and this is to look for the SCP in AD first (set with Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.domain.com/autodiscover/autodiscover.xml). The SCP defaults to the https://FQDNofCASServer/autodiscover/autodiscover.xml. If not found, the client will attempt https://SMTPdomain.com/autodiscover/autodiscover.xml then it'll try https://autodiscover.SMTPdomain.com/autodiscover/autodiscover.xml.

testconnectivity.microsoft.com goes through the same process and as it's not part of the domain nor can it access your AD, it starts with https://SMTPdomain.com/autodiscover/autodiscover.xml but should then try https://autodiscover.SMTPdomain.com/autodiscover/autodiscover.xml. Is this not the case?

Thanks.

Thanks Mark,

yes this is the case.According to this article it is correct as you stated.https://technet.microsoft.com/en-us/library/jj984202(v=office.16).aspx

domain.com

autodiscover.domain.com

_autodiscover._tcp.domain.com

During Exchange 2013 setuo, my TMG wasn't setup to listen to domain.com:443 and was only setup to listen to autodiscover.domain.com,It worked perfectly fine.

Now with same setup it is failing. If I setup account manually (enter mailboxguid and servername) then it works fine. (but then the purpose of autodiscover and easy setup is gone) 

If computer is within domain it works fine as well.

if computer is outside domain then it is failing with error

"The action cannot be completed. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action."

I have installed correct Root certificate on that computer, and can browse OWA without any issues.

I have setup TMG to listen to domain.com on same listener as autodiscover.domain.com,but outlook setup is still failing.

ActiveSync is working fine.

For your Exchange 2013 setup, this is as we set our servers up. Domain.com often points to a web server farm behind a different firewall so we can't use this for Autodiscover and we rely on the clients to fail then retry using autodiscover.domain.com. 

If you try to open https://autodiscover.domain.com/autodiscover/autodiscover.xml externally, you should be prompted for login details then get the below XML error. Let me know if this is the case. If so, this means that TMG is passing the traffic through to Exchange correctly. The client should trust this certificate so there should be no warnings in IE when the URL is opened.

Please can you post the error messages (if any) when using Microsoft RCA (http://testconnectivity.microsoft.com) under the section "Attempting to test potential Autodiscover URL https://autodiscover.domain.com". 

If no errors here then please post the errors under the section "Testing RPC over HTTP connectivity" as it should have progressed to this step.

Do the clients trust the CA that has issued the Exchange certificate which is configured for use by the IIS service?

Thanks.

HI Mark and thanks for reply,

yes I can browse autodiscover.xml file (prompt for username and password).Receiving same message as you mentioned.

Yes it is pass thru TMG,as I can see in the TMG log.

Clients has root CA installed and trusted,so browsing OWA does not give any cert error.

Test connectivity fails under domain.com, but all successful under autodiscover.domain.com

I cannot see "Testing RPC over HTTP connectivity" section as you mentioned.

This is last step of the connectivity test:

IIS on Exchange is setup with correct Cert (frontend and backend part of iis).

Normally when setup account manually in Outlook ,it should ask you last time for username and password right before its successfully created.For me it fails on third step,logon to mail server.

I did enable failed request logging on IIS, but no error files are generated.Cannot see anything in the autodiscover log folder either...

Testing RPC over HTTP connectivity should be listed as one of the test steps on RCA. If you're not seeing it then there should be an autodiscover error or other error higher up in the test or you're not using the "Outlook Connectivity" test. 

Please can you check you're using the correct test and then post the errors under the section "Testing RPC over HTTP connectivity".

Also, check the RPC Client Access logs which are in 
"C:\Program Files\Microsoft\Exchange Server\V15\Logging\RPC Client Access" or whichever path you installed Exchange in on the CAS server in Exchange 2013 so will be in a similar location on Exchange 2016.

It's worth checking the security log on Exchange, TMG and your DCs to ensure that there are no Kerberos related issues. You could try eliminate this cause by changing the ExternalClientAuthenticationMethod setting using Set-OutlookAnywhere. You can confirm that the setting is changed as you'll see this in Outlook settings after autodiscovery, in the autodiscover response in RCA and also in the Test E-mail AutoConfiguration results (ctrl-shift-right click the Outlook icon on the notification are). If you find that the change is not accepted, you can recycle the Autodiscover app pool in IIS and restart Outlook.

You can also do logging in TMG 2010 when trying to set up Outlook as it may report some authentication or other issues.

It's tricky troubleshooting Exchange 2016 when the documentation is not out yet (well, not fully!). Let me know how it goes.

Thanks.

Hi Mark and thanks for update.

TMG wise it says ok 200 so its not authentication error there.

Already recycled autodiscover app pool (and also the other),but same problem.

No security error log on both Exchange and DC.

Outlookanywhere is set to Basic (externalclientauth) and NTLM for Internalclientauth. IIS auth is set to basic,ntlm and Negotiate.

Test E-mail AutoConfiguration is not possible,since Outloook profile creation is failed.

Please can you also check the MAPI over HTTP log which you'll find below:

• %ExchangeInstallPath%Logging\MAPI Address Book Service\

• %ExchangeInstallPath%Logging\MAPI Client Access\

• %ExchangeInstallPath%Logging\HttpProxy\Mapi\

TMG is end of life and it's likely that MS won't support it for Exchange 2016. Perhaps worth looking at using a Web Application Proxy instead.

Thanks.

I think that Outlook may not yet know the 2016 Exchange and does not correctly answer the autoconfiguration.

I remember that as long as the update for Outlook is not released, problem working with Exchange 2013 RTM

TMG will definitely not support Exchange 2016 as it does not know how to work with MAPI over

I think that Outlook may not yet know the 2016 Exchange and does not correctly answer the autoconfiguration.

I remember that as long as the update for Outlook is not released, problem working with Exchange 2013 RTM

TMG will definitely not support Exchange 2016 as it does not know how to work with MAPI over HTTPS

Exchange Server 2016 Client Access Namespace Configurati

Thanks for reply,as mentioned earlier its not an issue with TMG since it passes the request successfully.

Still think its a Exchange related issue,so might be the MAPI that is causing it.

During profile creation in Outlook,it fails on the last step.

Will check the log and get back :)

Hi all then I figured the cause of error.

Get-mapivirtualdirectory says internalurl was set to https://ex01.domain.local/mapi

ex01.domain.local was not in the certificate,only ex01.

So I changed url to mail.domain.local/mapi and it worked!

Thanks for your time!