I'm not sure of the proper sequence of events when autodiscover initiates because what I thought I understood of the process is not what is actually occurring.  Initially I thought it was https://domain.com/autodiscover.... then https://autodiscover.domain.com/auto.... (etc.)  After further investigation it looks like SCP is the first stop for a domain joined PC.  Regardless, I am having issues and it all revolves around autodiscover looking for the root domain.

My issue is with both domain joined and non-domain joined PC's.  When attempting to configure outlook 2013 I am running into the following situation:

Based on what I'm seeing, autodiscover is looking first for https://domain.com/autodiscover...  My problem with that is that our company web site (domain.com) is hosted on a server that is not part of my environment.  Autodiscover is finding this server first and immediately throws the security alert regarding the names not matching (which it should because the server it's hitting is not mine and doesn't have anything to do with my exchange environment).  I have not been able to configure a non-domain PC yet.  With a domain joined PC I can at least get past the security alert and configure the client.

My question is, how can I prevent autodiscover from looking for https://domain.com/autodis.....  as the first step in the process?  I tried the reg settings found here http://support.microsoft.com/kb/948981  the link is for exchange 2007 but I figured it was worth a try.  I have also tried using a local XML file which has not worked either.  I found another thread that referenced using a host file with the desired URL and that did not work.

One strange thing to note on the domain joined PC.  When I run the "Test E-mail Autoconfiguration" tool from the outlook client it doesn't even reference the root domain URL in the log.  It listed the URL that it found via SCP which is the URL I want it to go to.  However it still throws the security alert because it's still looking up the root domain url.  Why is it looking up the root domain URL if it found what it needed via SCP?

Thanks for your time.

My suggestion is to see if your website hoster will make sure that it doesn't respond to https://domain.com/autodiscover... at all.

Thanks Ed, I will take your suggestion into consideration.

Shouldn't this be considered a design flaw with the autodiscover process?  Why would we not look for https://autodiscover.domain.com.. first versus looking for domain.com first?  Other than the MX record, the Exchange 2013 post installation steps do not reference needing a DNS entry for domain.com, only that you need mail.domain and autodiscover.domain, etc.  Why would we assume that the root domain server would respond to autodiscover requests?.  In most cases it's going to be a web server hosting a companies web site resulting in a 404 page not found...  This would be considered unsolicited traffic as far as the web server is concerned.

Even in the case where the SCP record is found the client still looks to the domain.com server for the certificate resulting in a security alert because the hosting web server does not have my certificate installed (why would they...).  Why would it not look for the cert at the URL that SCP returned?

Thanks.

While I must agree with you in my experience I have yet to see an organization who published Autodiscover on the root domain, ranting about it won't fix your problem.

I thought my questions were legitimate.  I'm not sure how they could be misconstrued as "ranting".  Maybe if I WAS YELLING or ending my questions with ????!!!!  I could see....  These questions were not directed at you individually but to the community as a whole.

I took your first suggestion and I did contact the company hosting our website.  I am waiting for a response.  So thanks again for that recommendation.

I'm looking for solutions and in order to understand why the lookups are occurring in the order that they are I need to ask those questions.  If there is a reason for it then great.  If these questions spark a change in the autodiscover order then even better as it will help many others, not just myself.  I know I'm not the only one having this issue.

You mentioned "in my experience I have yet to see an organization who published Autodiscover on the root domain" and that begs the question why are we looking at the rootdomain as the first step in the autodiscover process...

You're still on that rant, I see.  Complaining about the way things are is ranting.  The Autodiscover process is what it is and it isn't going to change now.

I support you fully, your question was polite and relevant, and I would also be surprised why this has never been addressed. While Ed is undoubtedly an enormously resourceful and helpful guy, it is painful to read that kind of arrogant replies from a pro (his tagline is perhaps not a little ironic). We are having the same problems - with almost 10.000 unmanaged Outlook clients in the WAN outside the security perimeter and domain, the municipality faces a barrage of hits on its root domain hosting servers that has to be eliminated by the gateway. Not an elegant solution at all. At least this thread makes is very clear that this is not a problem that can or will be addressed, outside a redesign of our solution. --- Jorn

You can call me arrogant if you want, but I'm trying to tell you the simple truth.  Your rant won't fix the problem either.  Every Outlook client and every mobile device I'm aware of checks Autodiscover in the same way.  Even if a change were made it would take years before you'd be unaffected by this problem.  The proper place to address this is with the team responsible for publishing your web page; surely they've had other customers with the same problem.  If they don't have a way to fix it, i.e., ignoring the domain Autodiscover URL, then you ought to consider changing web hosting companies.

Thanks for responding on such an old thread. You have indeed made it abundantly and admirably clear that this is not a solveable issue and has to be worked around by rejecting queries to the root domain for those who have this problem. It is not the technical content I took the liberty to criticise, as I mentioned it was very helpful to get a clear message that nothing can and will be done so stop the queries (in fact using the SCP is another solution when the clients are in a domain). I reacted negatively to the tone and especially the word "rant" that you repeatedly used (and still use) to put down our comments. I find is sometimes helpful to hear how other react to our behaviour, even if we do not immediately agree, and I am happy you took time to read mine. I would like to moderate the suggestion that I called you arrogant, perhaps a fine distinction but I called the tone of your reply arrogant. I have not seen enough of your other comments to dare comment on your general behaviour, which I am sure is fine. But as technical people we naturally tend to focus on the content rather that the social implication of our words. Friendly regards from Jorn!

I don't see the thread age so much, I see that one of "my threads", one I've posted in, is unread.

Actually, there is a solution of sorts.  You can push out a GPO to direct Outlook to skip looking for the domain URL.

https://support.microsoft.com/en-us/kb/2612922

But this doesn't help you for machines that aren't domain-joined.  For those, you'd have to tell users how to manually make the change or something.

If there is a bug in software and someone explains the problem with the bug, is that a rant? With Autodiscover there was a bug in the developers that thought it up. It takes away control from the ones implementing it. The software thinks it knows best.

How many companies do you think percentage wise have their Exchange server answering on 443 for their root domain? I would say it is a very, very small percentage compared to how many use autodiscover.domain.com. Autodiscover should check for autodiscover.domain.com first because you have much more flexibility with a subdomain than you do your root domain.

The issues that are caused by it looking for the root domain can be very frustrating on top of the fact that when it fails most technicians will look for hours/days at their Exchange implementation before they ever think that their outside shared hosting website could be causing the issues.

Anyone with a clue can tell that the Autodiscover process should at least be changed to look at autodiscover.domain.com first then fail to domain.com at the very least.

I can't speak for the Exchange and Outlook development teams, but I'm extremely certain that the response would be that it's not a bug, but by design.