- Exchange
- Outlook
- Email Servers
- DNS
Exchange 2010 Autodiscover and Mac
I am converting from SBS Exchange 2007 to a new Exchange 2010 server. All of the testing was successful and we had a few PC users running on the new server prior to the primary cut over which was tonight.
After making the new Exchange 2010 server live. I ran into a host of weird problems. The autodiscover service keeps failing with internal error 500 or says in couldn't be contacted. Autodiscover is only responded to the internal server name and not the external server name in any of the responses. And all DNS records (including autodiscover dns) have had the IPs updated to reflect the server change.
Because autodiscover seems to be broken, all testing using https://www.testexchangeconnectivity.com fails. I have rebuilt autodiscover with EMS multiple times as well as followed the instructions here for a manual rebuild from the exchange CD: http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/A_4962-7-Steps-to-AutoDiscover-Heaven.html
I have attached the test-outlookwebservices output for further review.
Ok here is the weird part. Everything except Mac laptops works perfectly. OWA works perfectly. SSL is responding correctly. Iphones and Droids connect. PCs connect using RPC over HTTP (Outlook Anywhere). PC Outlook of course will not auto config, but if you manually add the server settings, it works right.
The EWS with Mac Mail, Entourage, and Outlook 2011 just will not work. I assume its because everything responds with the internal server name versus the external name when queried.
I have double checked all server settings against another Exchange 2010 configuration that I have and cannot find anything wrong.
Looking for some ideas to get autodiscover working properly and the MACs connected to exchange. There were no issues with either of these on the Exchange 2007 server.
Thanks
Outlookwebservices.docx
Connectivity-Test-Failed.docx
After making the new Exchange 2010 server live. I ran into a host of weird problems. The autodiscover service keeps failing with internal error 500 or says in couldn't be contacted. Autodiscover is only responded to the internal server name and not the external server name in any of the responses. And all DNS records (including autodiscover dns) have had the IPs updated to reflect the server change.
Because autodiscover seems to be broken, all testing using https://www.testexchangeconnectivity.com fails. I have rebuilt autodiscover with EMS multiple times as well as followed the instructions here for a manual rebuild from the exchange CD: http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/A_4962-7-Steps-to-AutoDiscover-Heaven.html
I have attached the test-outlookwebservices output for further review.
Ok here is the weird part. Everything except Mac laptops works perfectly. OWA works perfectly. SSL is responding correctly. Iphones and Droids connect. PCs connect using RPC over HTTP (Outlook Anywhere). PC Outlook of course will not auto config, but if you manually add the server settings, it works right.
The EWS with Mac Mail, Entourage, and Outlook 2011 just will not work. I assume its because everything responds with the internal server name versus the external name when queried.
I have double checked all server settings against another Exchange 2010 configuration that I have and cannot find anything wrong.
Looking for some ideas to get autodiscover working properly and the MACs connected to exchange. There were no issues with either of these on the Exchange 2007 server.
Thanks
Outlookwebservices.docx
Connectivity-Test-Failed.docx
Oh yeah. Email is flowing properly and according to the other set of instructions for recreating autodiscover
Now going to your server on https://<Internal_CAS_Name_on_Cert
That is what I get from our server which means it is responding correctly.
Almost seems like I am forgetting something in the setup. But not sure what at this point.
Now going to your server on https://<Internal_CAS_Name_on_Cert
That is what I get from our server which means it is responding correctly.
Almost seems like I am forgetting something in the setup. But not sure what at this point.
Hi there,
from what i can see you have various problems:
Question 1: did you set the correct URL's in the CAS tabs in exchange
Question 2: did you make modify your DNS record extey (if needed)
Question 3: did you modify your firewall to NAT to the new server (since port 443 seems closed)
Question 4: did you follow the steps for using a wilcard certificate in exchange 2010?
from what i can see you have various problems:
Question 1: did you set the correct URL's in the CAS tabs in exchange
Question 2: did you make modify your DNS record extey (if needed)
Question 3: did you modify your firewall to NAT to the new server (since port 443 seems closed)
Question 4: did you follow the steps for using a wilcard certificate in exchange 2010?
Here are the the responses.
1. Yes, the correct URL's have been set in the CAS Tabs. I have tried modifying the internal URL's to match the external urls for OWA, ECP etc. But the URL's are correct
2. The DNS records have all been modified to reflect the new server. This includes both internal and external.
3. Yes. The firewall has been updated. The only port 443 that is failing is the root external domain and that is pointing to a different IP for the main website. The external sub domains, mail, autodiscover are all point correctly with 443 open.
4. Yes, the wildcart cert with principal name was set.
All of the server settings pass the testexchaneconnetivity.com
1. Yes, the correct URL's have been set in the CAS Tabs. I have tried modifying the internal URL's to match the external urls for OWA, ECP etc. But the URL's are correct
2. The DNS records have all been modified to reflect the new server. This includes both internal and external.
3. Yes. The firewall has been updated. The only port 443 that is failing is the root external domain and that is pointing to a different IP for the main website. The external sub domains, mail, autodiscover are all point correctly with 443 open.
4. Yes, the wildcart cert with principal name was set.
All of the server settings pass the testexchaneconnetivity.com
http://www.windowsinfo.eu/?p=236
did you do this step to support the wildcard?
it's not enough to just put * in the principal name...
Sorry if you alredy answered, but did you also setup iternal dns with an A record for autodiscover, with the external hostname?
if you ping autodiscover.yourdomain.lo
do the addresses resolve correctly?
did you do this step to support the wildcard?
it's not enough to just put * in the principal name...
Sorry if you alredy answered, but did you also setup iternal dns with an A record for autodiscover, with the external hostname?
if you ping autodiscover.yourdomain.lo
do the addresses resolve correctly?
Yep. Both the wildcard and the internal dns for autodiscover are correct.
If you run the get command on the cert it will pull up the wildcard.
The www.testexchangeconnectivity.com site gets hung up everytime at:
ExRCA failed to obtain an Autodiscover XML response.
Additional Details
An HTTP 500 response was returned from Unknown.
Followed by:
ExRCA failed to get an HTTP redirect response for Autodiscover.
Additional Details
An HTTP 403 forbidden response was received. The response appears to have come from Unknown. Body of the response: You do not have permission to view this directory or page.
Which to me mean the authentication would be wrong on the autodiscover VD. But I have recreated the VD 5 times at least.
The exchange tester does validate the wild card cert.
If you run the get command on the cert it will pull up the wildcard.
The www.testexchangeconnectivity.com site gets hung up everytime at:
ExRCA failed to obtain an Autodiscover XML response.
Additional Details
An HTTP 500 response was returned from Unknown.
Followed by:
ExRCA failed to get an HTTP redirect response for Autodiscover.
Additional Details
An HTTP 403 forbidden response was received. The response appears to have come from Unknown. Body of the response: You do not have permission to view this directory or page.
Which to me mean the authentication would be wrong on the autodiscover VD. But I have recreated the VD 5 times at least.
The exchange tester does validate the wild card cert.
Ok i think what is happening is the old exchange server 2007 on the SBS server is still trying to respond to the Autodiscover requests, even though the internal and external dns have been updated.
Also when i run the get-clienaccessserver command it shows the correct external autodiscover path on the old exchange server
and the autodiscover path on the new server is only set as the internal.
Once the rest of the mailboxes are moved off the old exchange server, i will be disabling all of its servers so it cant respond and then see what I get.
Everything checks out other than that.
Also when i run the get-clienaccessserver command it shows the correct external autodiscover path on the old exchange server
and the autodiscover path on the new server is only set as the internal.
Once the rest of the mailboxes are moved off the old exchange server, i will be disabling all of its servers so it cant respond and then see what I get.
Everything checks out other than that.
Yep...confirmed that the SBS 2008 Exchange Server is still hijacking some of the autodiscover feature.
After re-enabling the service. exchange connectivity tests passed. Of course mailboxes won't work since they are moved.
I have to get rid of Exchange 2007, but have hesitant on what might break.
Going to stop all exchange services and sites and see if that helps. But this looks rooted in deeper.
After re-enabling the service. exchange connectivity tests passed. Of course mailboxes won't work since they are moved.
I have to get rid of Exchange 2007, but have hesitant on what might break.
Going to stop all exchange services and sites and see if that helps. But this looks rooted in deeper.
OK after some difficulty removed all of the client access services from the exchange 2007 server. Switched from a wildcard cert. To SAN with all of the DNS names explicitly listed.
Recreated the autodiscover VD again thru the EMC in 2010.
Restarted IIS.
I am still consistently getting the 500 internal Server Error. Service Could not be contacted.
So everything manually configured is work except Autodiscover and EWS. Driving me crazy now.
Recreated the autodiscover VD again thru the EMC in 2010.
Restarted IIS.
I am still consistently getting the 500 internal Server Error. Service Could not be contacted.
So everything manually configured is work except Autodiscover and EWS. Driving me crazy now.
My Exchange 2010 server is finally up and running after transitioning from SBS 2008 Exchange 2007.
This should have been simple but the SBS server was conflicting on all of the autodiscover and EWS services. 2 years ago, I had to contact Microsoft as the Outlook Anywhere feature just broke out of the blue. In 13 years, it was the only time I have never been able to figure out an issue. It took the Microsoft team 8 hour days for a week to figure out what happened, and I am not sure what the fixes were that they implemented. But based on my experience this weekend, I believe that the MS team somehow hard coded Pointers to the SBS server for the Exchange Web Services in 2007.
After a lot of difficulty, I was able to remove the client access server pieces and the hub transport pieces off of the SBS server and finally broke the hold it had over Exchange 2010.
After that, I continued to get the 500 Internal Server error with the wild card certificate from godaddy installed. A setup that I have used a bunch of times on other exchange servers. The default web site had way too many bindings. 443 to localhost, 443 to 127.0.0.1. net pipe, net tcp bindings as well.
These extra bindings were put in automatically from the install. I removed those bindings and only kept on for port 80 and one for port 443 (no header info) then I replaced the wildcard cert with a SAN cert with 7 of our internal/external domains names and it worked immediately.
If you ever get a 500 internal server error related to autodiscover you need to check your certs and the associated bindings.
I still have a problem removing the mailbox service from the Exchange 2007 server. It states that the public folder replicas aren't moved. And I have verified that they have (plus we aren't using Public Folders anyway). So that will be the next challenge so I can completely remove Exchange 2007 from the environment. Probably have to use ADSI edit and manually remove the Public Store DB from the system.
This should have been simple but the SBS server was conflicting on all of the autodiscover and EWS services. 2 years ago, I had to contact Microsoft as the Outlook Anywhere feature just broke out of the blue. In 13 years, it was the only time I have never been able to figure out an issue. It took the Microsoft team 8 hour days for a week to figure out what happened, and I am not sure what the fixes were that they implemented. But based on my experience this weekend, I believe that the MS team somehow hard coded Pointers to the SBS server for the Exchange Web Services in 2007.
After a lot of difficulty, I was able to remove the client access server pieces and the hub transport pieces off of the SBS server and finally broke the hold it had over Exchange 2010.
After that, I continued to get the 500 Internal Server error with the wild card certificate from godaddy installed. A setup that I have used a bunch of times on other exchange servers. The default web site had way too many bindings. 443 to localhost, 443 to 127.0.0.1. net pipe, net tcp bindings as well.
These extra bindings were put in automatically from the install. I removed those bindings and only kept on for port 80 and one for port 443 (no header info) then I replaced the wildcard cert with a SAN cert with 7 of our internal/external domains names and it worked immediately.
If you ever get a 500 internal server error related to autodiscover you need to check your certs and the associated bindings.
I still have a problem removing the mailbox service from the Exchange 2007 server. It states that the public folder replicas aren't moved. And I have verified that they have (plus we aren't using Public Folders anyway). So that will be the next challenge so I can completely remove Exchange 2007 from the environment. Probably have to use ADSI edit and manually remove the Public Store DB from the system.
Explore More ContentExplore courses, solutions, and other research materials related to this topic.
-
![]()
received a Solution
Autodiscover not working, middle of Exchange 2010 to 2016 migration. Need help with DNS / URL's and SCP -
![]()
wrote an Article
![]()
Fix for Exchange server 2019 certificate and related issues
-
![]()
created a Video
![]()
Exchange 2013: Creating a Contact
-
Explore Cloud Class® ![]()
70-662 - Deploying Microsoft Exchange Server 2010
Premium Content
You need an Expert Office subscription to comment.Start Free Trial