Exchange 2013, Extended Protection, Outlook for Windows can no longer connect

Al Doman 61 Reputation points
  • On-prem Exchange 2013 CU23 + all patches, on Server 2012 R2. Bare-metal server is the AD PDC as well as hosting Exchange
  • Local Windows domain is company.local, Exchange server hostname is
  • Mail domain is External DNS MX record points to
  • The server has a trusted 3rd-party cert for There are also 2 self-signed certs for
  • Internal and public DNS are (I believe) configured properly. Both and resolve properly from either outside or inside the LAN and are appropriately reachable

Previously, Outlook for Windows clients (M365) worked fine. Exchange mailboxes were set up while was resolvable (either on LAN or connected via VPN). The only nagging issue is that every time Outlook starts, one or two certificate errors came up because the trusted 3rd-party cert ( didn't match the (presumed) server name under which the Outlook account was set up ( The users could bypass the warning (i.e. proceed anyways) and Outlook worked as expected.

After configuring Extended Protection by running the script (ExchangeExtendedProtectionManagement.ps1), Outlook for Windows clients can no longer connect. They get a message:

“There is a problem with the proxy server’s security certificate. The name on the security certificate is invalid or does not match the name of the target site Outlook is unable to connect to the proxy server. (Error code 10)”

Users can no longer bypass this error message and they can't connect.

While installing EP I had to deal with some prerequisite failures:

  • TLS configuration had some items not configured as expected. I explicitly enabled TLS 1.2, 1.1 and 1.0 per
  • SSL Offloading was apparently set to True (I have no idea why, maybe default for Exchange 2013?). I ran this cmdlet to turn it off: Set-OutlookAnywhere 'SRV\RPC (Default Web Site)' -SSLOffloading $false -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true

After that the EP update script passed prerequisites and reported a successful installation. Outlook for Windows can't connect, Outlook for Mac works fine, most smartphones work fine.

I rolled back the EP update by running ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestoreIISAppConfig" and restarting the server, but Outlook for Windows still can't connect.

I think what might be happening:

  • The SSL offloading cmdlet may now force clients to connect with SSL so the Windows clients can't bypass the warning any longer
  • The ultimate root cause is probably the technical debt of originally setting up AD and Exchange using company.local and

Outlook for Windows apparently uses AutoDiscover (and RPC over HTTP). The online connectivity tester shows that the AutoDiscover URL is properly found, and it shows the AutoDiscover.xml result that's being returned. The XML has the string "" in 5 places. My guess is the most important location for this discussion is:

I think what I ultimately want to do is somehow get the XML to return "" at least for X-CalculatedBETarget, and anywhere else it makes sense.

I recognize this may not help with existing Outlook profiles that were originally created pointing to but it's not the end of the world if users need to delete their profiles and re-establish them. My thinking is this would get from AutoDiscover, and when connecting the server certs would work for that server name and the Outlook errors would no longer happen.

As a fallback I might experiment with the SSL offloading, setting external and internal clients to $false which might allow Outlook for Windows users to bypass the warnings as they did previously.

Thanks very much to everyone who made it through all of this, and thanks in advance for insights anyone may have.

Exchange Server Management
Exchange Server Management
Exchange Server: A family of Microsoft client/server messaging and collaboration software.Management: The act or process of organizing, handling, directing or controlling something.
7,015 questions
{count} votes