I'm starting the migration to Exchange 2013 from Exchange 2010.

We have 3 Exchange 2010 CAS in our main site, and 3 in our DR site - all in contoso.com published through TMG.

We have 3 Exchange 2013 CAS in our main site, and 3 in our DR site - all in contoso.com published through Netscaler.

A few clients have presented an issue when I move their mailboxes and archive mailboxes to the Exchange 2013 side.

I use the New-MoveRequest -Identity <user login name> from an Exchaneg 2013 shell.

In two cases so far the clients can access their mailbox fine, but attempting to access their archive presents the error "The set of folders cannot be opened. Microsoft exchange is not available."

Running test emailautoconfiguration on the client results in

Attempting URL https://webmail.contoso.com/Autodiscover/Autodiscover.xml found through SCP
Autofiscover to https://webmail.contoso.com/Autodiscover/Autodiscover.xml starting
GetLastError=0; httpStatus=400.
Autodiscover request completed with status code 400.
Autodiscover to https://webmail.contoso.com/Autodiscover/Autodiscover.xml failed (0x80004005)
Autodiscover to https://contoso.com/Autodiscover/Autodiscover.xml starting
GetLastError=0; httpStatus=404.
Autodiscover to https://contoso.com/Autodiscover/Autodiscover.xml failed 0x80004005)
Autodiscover to https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml starting
GetLastError=12007; httpStatus=0.
Autodiscover to https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml failed (0x80004005)
Srv record lookup for contoso.com startingAutodiscover URL redirection to https://webmail.contoso.com/autodiscover/autodiscover.xml
Autodiscover to https://webmail.contoso.com/autodiscover/autodiscover.xml starting
Autodiscover request completed with status code 400
Autodiscover to https://webmail.contoso.com/autodiscover/autodiscover.xml failed (0x80004005)
Srv record lookup for contoso.com failed (0x80004005) 

Attempting to create a new profile on these workstations fails (which is no surprise) In Outlook, in the current profile, the "server" has changed to the mailbox guid@contoso.com, and the mailbox name has changed to emailaddress@contoso.com

The users can send and receive email just fine, they only have problems with their archives.

I have no A record in DNS, just the SCP which is identical on all 12 of my CAS. the 6 CAS in my main site have three sites in their keywords, and the ServiceBindingInformation of https://webmail.contoso.com/Autodiscover/Autodiscover.xml.

What am I missing?

Thanks

Karl

According to the symptom you provided, AutoDiscover was once working but somehow it's not working now. These users should not be able to download OAB update, do free/busy lookup, configure auto-reply because all these are based on autodiscover.

I would suggest to test autodiscover on other 'healthy' client first. This will help to narrow down whether the problem is at the client or server side.

Hi Karl,

According to your posting, the Autodiscover service doesn't work in your Exchange 2013. And there is no A record for Exchange 2013.

Please make sure the webmail.contoso.com and autodiscover.contoso.com are pointed your Exchange 2013 in DNS. And make sure there is an Exchange certificate which included these namespaces and assigned with IIS service.

If the issue persists, please run the Microsoft Remote Connectivity Analyzer tool to test the autodiscover service:

https://testconnectivity.microsoft.com/

The test results would list the test processing steps by steps. Please share the details here for further troubleshooting.

Regards,

I would suggest to test autodiscover on other 'healthy' client first. This will help to narrow down whether the problem is at the client or server side.

Hello,

Autodiscover works on many machines.

However, it's hit and miss.

When I was first moving towards Exchange 2013 I used a hosts file on my PC pointing both autodiscover.contoso.com and webmail.contoso.com to one of my 2013 CAS.

That worked fine. When we got the netscaler in place (initially publishing as webmail2013.contoso.com to avoid having all of our mailboxes hit that load balancer and the 2013 CAS, I had problems with my hosts file pointing at the netscaler VIP.

So, I changed my hosts file to point both autodiscover and webmail to CAS 1 and autodiscover worked., I pointed both to CAS 2 and autodiscover failed. I pointed both to CAS 3 and autodiscover worked.

It took some doing but I finally found that if I pointed webmail at CAS 2 and autodiscover anywhere else (CAS 1, 2, 3, or netscaler VIP), autodiscover worked. We found that CAS 2 had some security settings different than CAS 1 and CAS 3, so we resolved that, and on my workstation I could run an autoodiscover against all 3 CAS and the VIP.

CAS 2 is not currently part of the VIP though.

My question is if somehow my clients are still getting to the E2010 CAS for autodiscover?

Karl

Hi Karl,

According to your posting, the Autodiscover service doesn't work in your Exchange 2013. And there is no A record for Exchange 2013.

Please make sure the webmail.contoso.com and autodiscover.contoso.com are pointed your Exchange 2013 in DNS. And make sure there is an Exchange certificate which included these namespaces and assigned with IIS service.

If the issue persists, please run the Microsoft Remote Connectivity Analyzer tool to test the autodiscover service:

https://testconnectivity.microsoft.com/

The test results would list the test processing steps by steps. Please share the details here for further troubleshooting.

Regards,

Please make sure the webmail.contoso.com and autodiscover.contoso.com are pointed your Exchange 2013 in DNS. And make sure there is an Exchange certificate which included these namespaces and assigned with IIS service. Regards,

We are using a wildcard certificate here.

Karl

Have you checked the logs on the TMG to see if any Autodiscover traffic is still going through it? As long as your autodiscover SRV record points to your 2013 CAS servers, there shouldn't be any Autodiscover traffic going through your TMG. You can also check the IIS logs on the 2010 CAS servers to see.

Do you have any 2013 MB servers in your DR site or are they just CAS servers?  Is any of the client traffic going through the DR site when it shouldn't be?

Have you tried creating a new Mailbox user with archive and see if it works correctly?

Is the issue tied to specific users or it is random where a user won't work correctly one day and works fine the next?

I'm guessing that https://webmail.contoso.com/Autodiscover/Autodiscover.xml resolves to an IP on your Netscaler, correct?  Can you access that URL from your client's internal IP Subnet?

You can try using fiddler to capture the traffic on one of the affected clients and make sure all the URL's Outlook is getting are correct.

Last but not least, do you have all the patches and updates applied to your Outlook clients?  There have been quite a few hotfixes released for the current Outlook versions that address connectivity with Exchange 2013.

Have you checked the logs on the TMG to see if any Autodiscover traffic is still going through it? As long as your autodiscover SRV record points to your 2013 CAS servers, there shouldn't be any Autodiscover traffic going through your TMG. You can also check the IIS logs on the 2010 CAS servers to see.

There is no traffic to any of our old TMG rules.

Do you have any 2013 MB servers in your DR site or are they just CAS servers?

We have 8 mailbox server in main site, 4 in DR site in a 3 copy DAG.

Is any of the client traffic going through the DR site when it shouldn't be?

I am not sure, however it should work as the MB servers have a copy of the mailbox.

Have you tried creating a new Mailbox user with archive and see if it works correctly?

Yes, I have a test user with a new mailbox and archive and the autodiscover works fine on my workstation.

Is the issue tied to specific users or it is random where a user won't work correctly one day and works fine the next?

Right, I moved the boss of my boss yesterday, and his outlook client updated his profile to mailboxguid@contoso.com, but he could not access free/busy or his archive. This morning everything is fine.

I'm guessing that https://webmail.contoso.com/Autodiscover/Autodiscover.xml resolves to an IP on your Netscaler, correct?  Can you access that URL from your client's internal IP Subnet?

You can try using fiddler to capture the traffic on one of the affected clients and make sure all the URL's Outlook is getting are correct.

I may have to try that.

Last but not least, do you have all the patches and updates applied to your Outlook clients?  There have been quite a few hotfixes released for the current Outlook versions that address connectivity with Exchange 2013.

In this most recent case, the boss of my boss is using Outlook 2012 as part of the Office 265 suite. Let's hope Microsoft is keeping it patched. :)

Karl