During an Exchange 2010 SP3 to Exchange 2016 CU5 upgrade, some Outlook clients intermittently received the following certificate error message:
There is a problem with the proxy server's security certificate.
Outlook is unable to connect to the proxy server mail.domain.com (Error Code 80000000).
The error was only experienced after moving a mailbox from Exchange 2010 to Exchange 2016. The issue was also intermittent, not all workstations received the error message.
On the Exchange 2016 server the following was configured:
The server was configured with MAPI over HTTPS enabled on the organization configuration and all Outlook clients were creating MAPI over HTTPS connections to the server.
After much troubleshooting, we set the InternalClientsRequireSSL to $true and did an "iisreset" on the servers Outlook Anywhere configuration.
After changing InternalClientsRequreSsl to $true the issue did not occur.
There is a problem with the proxy server's security certificate.
Outlook is unable to connect to the proxy server mail.domain.com (Error Code 80000000).
All Outlook Clients were running 2013 SP1.
The error was only experienced after moving a mailbox from Exchange 2010 to Exchange 2016. The issue was also intermittent, not all workstations received the error message.
On the Exchange 2016 server the following was configured:
- A valid digital certificate from RapidSSL was installed on the Exchange 2016 server along with the intermediate certificate and root certificate.
- All names for Internal and External URLs were set to a name that matched the digital certificate for Outlook Anywhere, MAPI over HTTPS, Exchange Web Services, OAB Distribution and Autodiscover.
- DNS was configured to direct all connections to the new Exchange 2016 servers.
- We had a proxy exclusion in place on all workstations to ensure data to the Exchange server "mail.domain.com" was sent direct, not through the proxy.
The server was configured with MAPI over HTTPS enabled on the organization configuration and all Outlook clients were creating MAPI over HTTPS connections to the server.
After much troubleshooting, we set the InternalClientsRequireSSL to $true and did an "iisreset" on the servers Outlook Anywhere configuration.
After changing InternalClientsRequreSsl to $true the issue did not occur.
What is interesting about this, I set InternalClientsRequireSSL to $false in my Exchange environment running Exchange 2016 CU4 and restarted IIS, I was not able to reproduce the issue with Outlook 2016.
I also have other clients that have InternalClientsRequireSSL set to $false that are doing SSL Offloading via a load balancer running Exchange 2016 that do not experience this issue.
It is an interesting issue as it was intermittently occurring across workstations at my client site.
The issue was definitely related to InternalClientsRequireSSL as I tested setting it back to $false, as soon as changing it back to $false the issue immediately reoccurred.
Perhaps a bug between Outlook 2013 SP1 and Exchange 2016 CU5? InternalClientsRequreSsl is a valid setting and there are many cases where this must be set to $false.
Hope this post has been helpful.
This is dummy text. It is not meant to be read. Accordingly, it is difficult to figure out when to end it. But then, this is dummy text. It is not meant to be read. Period.
ConversionConversion EmoticonEmoticon