Use this as a .reg file

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeHttpRedirect"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"ExcludeScpLookup"=dword:00000001

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover\RedirectServers]
"yourmailserver.com"=hex(0):

Thank you Brian,

I'll try soon and let you know.

Brian,

the issue persists after modifying the registry. When it happens an informational event with Event ID 26 is recorded in Windows 10 Application Log.

As soon as we disable and re-enable the NIC the issue disappear for a while (usually 2/3 hours). But there's no other issue on the network when Outlook is disconnected.

Can you post the output from event viewer??

Here are the screenshots. They are in Italian, the EventData property means "Connection to Microsoft Exchange has been lost, Outlook will restore the connection when possible."

Office365 apps or what version of outlook??

Is IP6 enabled on the clients?

When using MAPI Outlook will regularly connect with several hostnames associated with the client's domain using an HTTPS connection, and if one of those is failing you'll likely see these types of disconnects when Outlook encounters the bad hostname. Outlook will always attempt to connect to these addresses periodically: 

- https://mail.customer-domain.com

- https://autodiscover.customer-domain.com

- https://customer-domain.com/autodiscover/autodiscover.xml

Are all three of the above addresses reachable from the affected client PCs? If not this would be a good place to start checking things out. If you can resolve any issues in the autodiscover process the sync issues will likely follow suit.

Also, +1 for Brian's note on IPv6. We have seen IPv6 introduce all sorts of trouble over the years!

Hi Kyle.

As I have already reported in the past, it is often not possible to make "https://customer-domain.com/autodiscover/autodiscover.xml" work/point correctly because whoever manages the customer's website is a different entity from us (and by the customer himself) and they really don't give the possibility to do so.

Furthermore, this is NOT reported as necessary, not even by Microsoft to connect MS Outlook to MS Exchange, so I don't see WHY it would be necessary when I connect it to SmarterMail.

We have literally many hundreds of users who use MS Outlook MAPI with Smartermail without EVER even configuring this address...

And despite this they have no problems.

Hello, in this specific scenario it's not a reachabilty issue: the accounts in all affected computers (about 15) are on the same network and have been configured using autodiscover. We are managing DNS for the domain and we set up autodiscover records, and SM has the certificates management in place for the domain names involved.

And by the way, re: Gabriele's note, on recent versions of Outlook there's no way to setup an Exchange account through MAPI without autodiscover.

To answer Brian's questions: Outlook version is 2016, and I've disabled IPv6 on some of affected machines with no success.

To clear the field I'm going to change the NIC on one computer to make sure it isn't something related to network hardware/driver.

<<<<<<<<<

my comment was only related to "https://customer-domain.com/autodiscover/autodiscover.xml".

The other 2 AutoDiscover records ( https://mail.customer-domain.com and https://autodiscover.customer-domain.com) are working fine and are sufficient

Yes Gabriele, you're right, I misread your post.

Sorry for that.

Would be useful to know from ST if the reachability of that record is necessary (like Kyle said) or not (like it appears to be as per your post).

Outlook 2016 has notorious issues in connecting to Exchange. It was solved in outlook 2019 and above.

https://learn.microsoft.com/en-us/exchange/troubleshoot/client-connectivity/outlook-connection-issue-caused-by-rpc-encryption-requirement

Have you checked the version of TLS on the server versus the affected machines??

@Comcentrica: it's not necessary. 

According to the MS knowledge base, the MS Outlook autodiscovery process tries various methods consecutively and uses the first one it finds that works (you can enable/disable those methods one by one in Windows Registry)...

I can confirm this because I have hundreds of domains configured and running with MAPI on my SmarterMail servers (and a few others on MS Exchange servers in the cloud) and NONE of them use this record.

Thank you Gabriele,

any of them are using Outlook 2016? Just to check against Brian's comment.

@Brian: the Exchange account has been configured with RPC cyptography by default, and the option isn't editable in the UI.

The computers are running Windows 10, so they should have TLS 1.2 enabled by default. SM is running on Windows Server 2022 with "System Default" option enabled in "Security Protocols".