I'm having autodiscover issues with the new Exchange 2013 server. I rechecked the authentication and its fine. I rechecked my certificate with SAL and it has autodiscover.mydomain.com in it. Services are assigned to the certificate.

However, when I run the remote test for outlook connectivity it states its having trouble with autodiscover.

My main domain used for all services is m1.mydomain.com and I have an A record out there on DNS servers on the internet. Do I need one also for the the autodiscover.domain.com?  The test states it cannot The Microsoft Connectivity Analyzer is attempting to test Autodiscover for mymailbox@domain.com  testing autodiscover failed.   The Autodiscover service couldn't be contacted successfully by any method.  Also all other tests failed. What am I missing? Do I need to configure the autodiscover area in virtual directories? Currently when I click on the wrench there is no information in there. None in the external address. is something suppose to be there?

Hi,

Yes, we need to point autodiscover.mydomain.com to your Exchange 2013 (TMG Listener) in your external DNS.

Alternatively, we can create a SRV record external DNS zone for autodiscover service with m1.mydomain.com to have a try:

Service: _autodiscover

Protocol: _tcp

Port Number: 443

Host: m1.mydomain.com

For more information about SRV record for the Autodiscover service, please refer to:

http://support2.microsoft.com/kb/940881/en-us (It is also applied for Exchange 2013)

Regards,

do you need the SRV record on the internal DNS servers?

adding srv record is usually best practise for following reasons:

If you dont have autodiscover,it will check srv record.

If you have multiple domains for your Exchange server

Protect against spam

It can also help if you have multiple domain and user1@domain1.com cannot share/view calendar of user2@domain2.com.

 For example, you have domain1.com and domain2.com on the same Exchange Server. user@domain1.com cant see user@domain2.coms calendar. The fix for this is to add the SRV record to the domain2.com DNS zone and point it to the public host name for domain1.coms mail server. Once thats done the services that operate the calendar sharing functions will be properly configured and both users will be able to share calendars.

https://acbrownit.wordpress.com/2012/12/20/internal-dns-and-exchange-autodiscover/

I finally got connected to the internal exchange server with outlook and then tried the external with Outlook Anywhere and this is what I discovered:

Not sure if this correct or not but this is what I observed. I checked the server settings of the profile I was connected with and notice a long SID number@mydomain.com  not sure if this is what suppose to be there or should it be mail.mydomain.com?

In the username it was not just my user name but my complete address such as john.smith@mydomain.com Is this what suppose to be there or just the username. Anyways it seems to be connecting and working. In my 2010 Exchange setup it was just the username.

When I checked on the Exchange Proxy Settings I observed this.  in the https: area it was the correct URL mail.mydomain.com.  Both the SSL only and Only connect to proxy servers that have the original principal name in their certificate are checked. In the box it lists msstd:mail.mydomain.com. This entry became populated automatically probably through autodiscover.

The Next two blocks are also checked, on fast and slow networks.

The type of authentication NTLM. 

Not sure if this all correct but it is different  that my 2010 Exchange server setup.

It does work though.

Hi Jackie,

number@domain.com is expected behaviour,since Exchange 2013 no longer uses cas array to Connect but mailbox guid.

To find a users mailbox guid you can run the following PowerShell command:

get-mailbox -Identity alias |fl exchangeguid

This command can be helpful if you one day need to manually configure New mailbox profile and autodiscover fails.