Mike, I noticed you submitted these details on an unrelated ticket along with a few other replies. In the interest of getting to the bottom of this one quickly - can I have you submit a separate ticket on the autodiscover issues so we can dig into this?

Hi Kyle---

Thank you for your reply.  I just replied to an email from Tony, thank you.  I wanted to see if anyone else has had this problem.  

Tony's line of questioning in his email was towards DNS and was about what IP address my autodiscover was pointed at as what he sees checking autodiscover outside my network is a different IP address than what Fiddler shows from a machine sitting behind my firewall.

Naturally the autodiscover IP is different for a machine sitting internally on my LAN than a machine trying to hit autodiscover on the outside internet.  

This internal IP address happens to the the same IP that Outlook 2016 autodiscover works with on my LAN.  

In my original response I included Fiddler logs for autodiscover queries on both Outlook 2019 and Outlook 2016 and if you look at the packets one can see both inquiries hit the same internal IP on my LAN.  I figured you would want to compare both Fiddler logs to verify that autodiscover works in 2016 to try and figure out the problem.

Anyway, I'll wait to hear more information.

Thanks Mike, I appreciate your follow up here. The DNS/Autodiscover suggestions Tony has passed along are for good reason at the very least :) Outlook these days uses a Microsoft-based discovery system to find account details and facilitate the connectivity, so the autodiscover deployment must be reachable from the outside in order for Outlook account set up to complete successfully. 

Because of this, differences between internal/external DNS can introduce issues and this is likely what he's looking at now. We do see issues like these occasionally and in most cases there is an internal DNS record pointing to an IP which isn't bound to the hostname in IIS, the SSL certificate for that hostname doesn't support being called on that IP, etc. When fully functioning both internal and external machines should be able to:

- Reach https://mail.customer-domain.com successfully and without security warnings. 

- Reach https://mail.customer-domain.com successfully and without security warnings. 

- Reach the SRV record you have set up in DNS which points to mail.customer-domain.com. 

Additionally, the requirements above need to be specific to the domain you're setting up a MAPI account for. So if the user account is customer-domain.com and you have everything pointing to mail.server.com this too can introduce issues due to how Microsoft is handling the account set up procedure. 

Based on your follow up though it sounds like these are checking out during your troubleshooting and we likely need to dig into the Fiddler traces further to see whats going on. Did you get a ticket submitted on this one already? If so please ping me with the ticket number and I can add some notes here as well. 

Hi Kyle---

I sent Tony all of the information and he has it in his possession.

Question, have you updated Outlook 2019 to the latest build and tested autodiscover on your network?  I've asked Tony a few times and not gotten an answer.  That seems to me a very easy and low time-expenditure place to start.

Thanks.

Thanks Mike, that should get us going in the right direction. My Outlook client version is fully updated (automatic updates) and I recently removed and re-added my account via autodiscover (due to a test I'm doing on syncing full account versus 1 year) and found it completed successfully and without errors. We have those requirements noted above in place, but I also have a couple of local workstation tweaks in place as well to help bypass Microsoft's authentication service due to it being a 365 install: 

First, add the following line to your C:\Windows\System32\Drivers\Etc\Hosts file:

127.0.0.1        outlook.office365.com

You'll need to save it to your desktop, then move it into its original home due to Windows security. Once you've replaced it, we'll need to add a DWORD registry value within your registry at:

Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

You can add a new DWORD property here and call it "PreferLocalXML" and set it to a value of 1. This tells Outlook to ignore any Office 365 autodiscover that it might be receiving, and use what it got from the SmarterMail server instead. When finished, do a reboot, create a new profile in Outlook and give it another shot. Perhaps these might help in your environment as well, at leas that way you know the data you're getting back from SmarterMail is whats being leveraged. Just figured I'd pass all of this along while you're awaiting Tony's findings. 

Hi Kyle---

I saw that you suggested this a few weeks ago to someone else and I had tried then.  I just double checked the settings, restarted and tried again.  No dice.

Question, what OS are you on?  Maybe OS related?

Mike - Thanks for trying that. What happens when you try to add your account with those modifications in place? My testing has been completed from Windows 7/Windows 10 and Windows Server 2016. 

Doug - I actually just followed up with you on my results on how EAS service access (in user settings) does not affect my ability to add MAPI accounts as you've pointed out. I'm not sure why this chunk is missing when you disable EAS functionality but think some research I did may have shed some light on the different pieces of the XML response.

Within the autodiscover XML the EXCH/EXPR sections are specific to the protocol in use, and may not be shown in all cases depending on which services the user has enabled. The EXPR section itself looks to provide web address URLs for Outlook Anywhere, which I do believe is MAPI functionality. So, this being missing is definitely the problem, but EAS changes do not look to be the root cause based on my results here.

Whats interesting is that in your environment disabling EAS is affecting your MAPI autodiscover results, but this does not happen in my testing here and in other environments. Please follow up with me on the support ticket in regards to overrides, as I don't think this was the silver bullet we were hoping for. 

I'm just circling back to this as I got involved in another project for a few months.  I re-installed win10 and Office 2019 on the machine.  It now connects with MAPI.  Unsure whether it has to do with changes on MS side, SM side, or just something I had done on the original config.  

Thanks for all who tried to help me in this thread.

Hello,

Could be related to this if you are now using the latest build.
https://portal.smartertools.com/community/a94092/autodiscover-not-working-for-mapi.aspx

Kind regards.

Thanks for pointing this thread out Sebastien---appreciate it.