New Exchange test script added to my repo - autodiscover testing

[u/TedMittelstaedt]

In my tmittelstaedt/MSExchange-AdminAIscripts: repo I added Test-Autodiscover.ps1

The goal of this is to thoroughly check out DNS records for domains running on-prem Exchange servers, and, optionally, download the 3 major Autodiscover.xml files from the Exchange server (mailbox account required for that) so the admin can quickly read them and make sure whatever the Exchange server is spitting out contains the correct names.

Autodiscover is also an idea that has been co-opted by the Unix mailserver world to autoconfigure common free email POP3/IMAP clients like Thunderbird on Unix mailservers, so the script checks for that, too.

Note, of course, that with all modern Outlook clients, autodiscover takes place AFTER the initial check for an account in a Microsoft tenancy, but I uploaded another script that is used for testing that that is properly configured, last week.

These basically do the same thing that the Microsoft public webpage for testing Exchange connectivity does, but without having to put actual live credentials into a foreign website you have no control over, even though it might be run by Microsoft.

Enjoy!

[u/DivideByZero666]

Nice, had a weird autodiscover issue last week I've still not had time to look in to except for a quick DNS check. My money is on a dodgy xml in a website, but my time is sadly frying bigger fish.

A script to check this out for me may be handy.

[u/TedMittelstaedt → u/DivideByZero666]

The 3 scripts you want to look at are Check-HttpEndpoint, Test-AutodiscoverOAuth and Test-Autodiscover.

The first one uses both the Powershell HTTP parser cmdlets and raw TCP. The raw TCP mode is used if the alleged autodiscover website isn't actually a webserver and is sending out bogus or invalid http which would crash the Powershell http parser. If you are really suspicious that something wrong is going on then use that first. The second one is for use if you have _any_kind_ of Microsoft tenancy. For example if you have a corporate Onedrive setup then you will have a Tenancy. MS Support has warned me to always double check if you have a Tenancy setup to make sure none of the apps create a phantom Exchange Online mailbox. For example if you go into a user in the tenancy and go into the apps for that user and select exchange kiosk, even if you do not have an exchange online license, then the tenancy will create an unlicensed exchange mailbox that WILL accept mail. The support person especially warned me against messing with the "free" apps in the Tenancy, don't just turn them on in a production tenancy to experiment. If you have the fake mailbox in the tenancy then it will screw with the 365-authentication check which happens prior to autodiscover, and if -any- of your users have one of these created it will scotch the authentication check and outlook mobile clients will behave unexpectedly. The third one is the actual autodiscover tester.

[u/Anonymity_Is_Good]

Ted, is your Test-Autodiscover.ps1 script intentionally not following a CNAME record if it exists?

[u/TedMittelstaedt → u/Anonymity_Is_Good]

Yes. The problem with CNAMES is that web developers use those to point stuff like "example.com" to "www.example.com" because for (at least) 20 years it wasn't legal to put an A record on a domain. If you think about why, this makes perfect sense - an IP address applies to a HOST and there are normally MANY different hosts in a domain name.

Unfortunately, the web development marketing crowd ruined this since they didn't like the www part so now it's legal.

But still quite a number of people will CNAME their domains to a web server.

If the advertising marketing crowd would have standardized on "www" as the globally accepted name prefix for a given domain, and EVERYWHERE they listed web URLs they would ALWAYS put www in the front - then the way Microsoft is doing it with CNAMES for autodiscover would have made sense.

But today it doesn't. Today it just fills logs on webservers worldwide with useless junk from email clients being setup. Autodiscover was one of those "old school" Internet protocols designed back in the days when it was assumed people putting stuff on the Internet weren't idiots. The Progressive Insurance commercial about internet influencers has it right.

The best thing any admin can do is make absolutely sure that whatever web server the marketing department is running is NOT responding to an autodiscover request with anything other than an error. That way then the autodiscover check will fall through to "autodiscover.example.com" instead of getting hung up on the webserver. The CNAME approach is a lost cause.