Link to home
Create AccountLog in
Avatar of hfcadmins
hfcadminsFlag for United States of America

asked on

Need help with External AutoDiscovery on Exchange 2010

I am currently working in a lab environment testing for a planned Exchange 2007 to Exchange 2010 migration.

My lab consist of:
2 Domain Controllers
1 Exchange 2007 Hub/Mailbox server (EX1)
1 Exchange 2007 CA server (EX2)
1 Exchange 2010 Hub/Mailbox server (EX3)
1 Exchange 2010 CA server (EX4)

My focus is on the 2010 CAS at this point. I have ActiveSync, OWA, and Outlook Anywhere all working just fine over HTTPS. All manual tests for ActiveSync & Outlook Anywhere from return good passing results. The CAS servers even redirect based upon the users mailbox location. I have a UCC cert from GoDaddy that is installed properly on the 2010 CA server, with the corresponding correct SAN's. I am using different public IP's for the external Outlook Anywhere & Autodiscover URL, and have these set right in IIS.

However, I've never attempted to make the AutoDiscover services work. I'd like to make the external autodiscover work so ActiveSync clients can simply enter their username & password. I believe this can also be done for Outlook Anywhere clients?

I have all proper ports open through our external firewall and believe I have all proper external DNS A records in place. Seems like I also correctly set the ExternalURL for the AutoDiscover virtual directory in IIS and Exchange. However, I'm not getting passing results for AutoDiscover from .

I'm including the screenshots that display the |fl output from the Get-AutodiscoverVirtualDirectory command, as well as 3 screens of the output from the Autodiscover tests from .

I have not done anything to the local DNS on the Domain Controllers.

I didn't think this would be very difficult. Thanks so much for any and all help!
User generated imageUser generated imageUser generated imageUser generated image
Avatar of chakko
Flag of United States of America image

Have you created DNS SRV records on the public internet, or the DNS servers authoritative for your domain (internal or external)?

Take a look at this article for information.

The SRV record for DNS is like this (linux DNS)

_autodiscover._tcp  14400  in  SRV  5  0  443 can be the CN on your SSL

Do you have a as part of your SAN cert? If not, it will not work.
Avatar of hfcadmins



If I am reading that article correctly, it seems to not directly apply to my setup, because I have a UCC certificate with multiple SAN names to it, multiple public IP's, etc. I have not created any internal or external SRV records. I guess I can do that and see where I end up.


Yes, I have "" setup as an external A record. Right in my screenshots I attached to my post, it shows the valid https connectivity to that URL as well as the validation of that SAN on the UCC certificate.

I'm not understanding what my issue is after it successfully connects to port 443 on "" and validates the certificate name, and checks IIS for certificate authentication. The next step, where it fails, is the attempt to retrieve the autodiscover.xml response. I can hit the address "" and login if I browse to it manually. However, it states a "HTTP 500 response was returned from Unknown" via the Exchange Connectivyty Test website. This is the part I don't understand why it's failing.

This can't be that difficult... can it ?? :(
Avatar of Jian An Lim
logically, you should able to access and get the xml display.

Have you run your Exchange Best practice analyzer?
Maybe the IIS is not being setup correctly for this instance
Avatar of hfcadmins
Flag of United States of America image

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Resolved my own issue
You don't need multiple IPs to configure your 2010 access. You can publish all through a single public IP & one certificate. Yours is complicated setup. Any reason?
It's actually not a complicated setup - I made it more complicated than it needed to be :)

Hadn't ever worked with a UCC certificate before, so I was use to having to use distinct different IP's for each SSL certificate. Again, just made more IP bindings in IIS than was needed, ended up breaking the autodiscovery from working.

I did the same thing, added machine name to the binding, because I've always done that, and that was exactly what was wrong!

I spent THREE DAYS figuring this out.

Hah right on! Glad to see my fix details helped someone else out :)