none
There is a problem with the proxy server's security certificate error when starting Outlook.

    Question

  • We've just deployed Exchange 2013 CU2 and migrated our users from 2007. We have a two-node cluster behind a load balancer. Each node has both a CAS and Mailbox roles. We have a third-party certificate through DigiCert and took the advice/best practice of not adding the server names to the subject alternative names in the certificate. All services and urls are working as expected with the exception of Outlook Anywhere.

    When Outlook starts (happens on both Outlook 2010 and 2013), it connects to oa.domain.tld, which points to our load balancer. They are then forwarded to EXCH01 or EXCH02 in round-robin fashion. Clients who connect to EXCH01 do so without issue. Clients who connect to EXCH02 receive the error: 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 EXCH02.domain.tld. Outlook is unable to connect to the proxy server. (Error Code 10).

    I've compared the configuration on both servers. Both have our valid SSL cert installed and mapped to IIS and SMTP. When I browse to https://exch02/rpc, and view the certificate, I see oa.domain.tld in the subject alternative names as expected. In the ECP, I've compared the Outlook Anywhere settings on the Server objects and they both have oa.domain.tld specified for the external and internal host name, and NTLM is set as the authentication method. This has been validated by get-OutlookAnywhere | fl, and comparing the results between EXCH01 and EXCH02; they are identical.

    Once a client acknowledges the error, they can get to their mail without issue. When looking at the Outlook connection status, everything is pointed to the Proxy Server oa.domain.tld correctly. Running Test E-mail AutoConfiguration also came back as expected. The server name EXCH02 is never referenced in any of the results.

    Where else can I look to diagnose why Outlook clients connecting to EXCH02 get the certificate error?



    • Edited by Chuck Lawton Wednesday, October 30, 2013 4:11 PM Updated to denote 2013 CU2
    Wednesday, October 30, 2013 3:55 PM

Answers

  • I ended up opening a support request with Microsoft on the issue.

    All of our server settings were correct. We additionally added the certprincipalname value on our Outlook Provider settings to provide outlook with the expected principal name on our certificate as Outlook Anywhere was set to connect using one of the subject alternative names, but that did not have any effect on our environment.

    BTW: The commands for that are:

    set-outlookprovider -Identity EXCH -CertprincipalName msstd:webmail.domain.tld
    set-outlookprovider -Identity EXPR -CertprincipalName msstd:webmail.domain.tld

    It turns out that there was a short period of time in which EXCH02 did not have the correct Outlook Anywhere settings in the server object in ECP. They had the default local server values of EXCH02.domain.tld. This value matched the error that Outlook was throwing.

    As soon as we discovered the oversight on the first day that users were firing up Outlook after migration, we updated the settings. However, users that had connected to EXCH02 via our load balancer while the default settings for Outlook Anywhere had been applied had the incorrect server name cached in their Outlook profile.

    Correcting this required generating a new profile and deleting the existing profile on the affected users Outlook. Alternatively, you could delete the user's .ost file, where the cached information was stored, which would preserve the user's Outlook Profile and begin a resync of their mailbox upon Outlook's next startup. This was critical for us as we had users with Dynamics CRM 4.0 installed into their existing Outlook profile, and we did not want to set all of these users up from scratch again.

    • Marked as answer by Chuck Lawton Friday, November 01, 2013 8:26 PM
    Friday, November 01, 2013 8:26 PM

All replies

  • Just experimenting now. I created a host file entry on my computer to point oa.domain.tld to EXCH01's IP and I *still* get the certificate error referencing EXCH02. This bypasses our load balancer and should direct the connection to EXCH01. How is EXCH02 getting involved? My mailbox is on a database that's mounted on EXCH01...
    Wednesday, October 30, 2013 5:09 PM
  • Hi Chuck,

    I have not installed Exchange 2013 until now, but I found two hyperlinks that may help you:

    http://social.technet.microsoft.com/Forums/en-US/e6a42eca-7ba7-4012-863d-7881e6026982/exchange-2013-certificate-error

    http://3techies.com/?p=194

    May there are not all URLs changed to point your load balancer?

    With kind regards

    Cybiria


    Thursday, October 31, 2013 7:25 AM
  • I read through the information in the 3techies.com article, and verified that all of my virtual directories are  correct and identical. None refer to a server name and all use the various namespaces we set up and added to our external certificate are there. I also verified that the AutoDiscoverServiceInternalUri is set to https://webmail.domain.tld/autodiscover/autodiscover.xml for both EXCH01 and EXCH02 CAS roles via get-clientaccessserver.

    So it would appear that per the steps outlined in 3techies.com regarding setting up namespaces correctly, we should be good. But we still get the proxy server security certificate error on EXCH02.

    I verified that all of the A records for all of the services resolve to our load balancer virtual IPs and that they map to the two server IPs. We split the namespaces out to aid in troubleshooting and to give different persistence options for the connections in the load balancer, so we have:

    webmail.domain.tld
    autodiscover.domain.tld
    oa.domain.tld (outlook anywhere)
    mobile.domain.tld (for active sync devices)

    They are all defined properly in both Exchange servers, DNS and the load balancer.

    Thursday, October 31, 2013 1:35 PM
  • I ended up opening a support request with Microsoft on the issue.

    All of our server settings were correct. We additionally added the certprincipalname value on our Outlook Provider settings to provide outlook with the expected principal name on our certificate as Outlook Anywhere was set to connect using one of the subject alternative names, but that did not have any effect on our environment.

    BTW: The commands for that are:

    set-outlookprovider -Identity EXCH -CertprincipalName msstd:webmail.domain.tld
    set-outlookprovider -Identity EXPR -CertprincipalName msstd:webmail.domain.tld

    It turns out that there was a short period of time in which EXCH02 did not have the correct Outlook Anywhere settings in the server object in ECP. They had the default local server values of EXCH02.domain.tld. This value matched the error that Outlook was throwing.

    As soon as we discovered the oversight on the first day that users were firing up Outlook after migration, we updated the settings. However, users that had connected to EXCH02 via our load balancer while the default settings for Outlook Anywhere had been applied had the incorrect server name cached in their Outlook profile.

    Correcting this required generating a new profile and deleting the existing profile on the affected users Outlook. Alternatively, you could delete the user's .ost file, where the cached information was stored, which would preserve the user's Outlook Profile and begin a resync of their mailbox upon Outlook's next startup. This was critical for us as we had users with Dynamics CRM 4.0 installed into their existing Outlook profile, and we did not want to set all of these users up from scratch again.

    • Marked as answer by Chuck Lawton Friday, November 01, 2013 8:26 PM
    Friday, November 01, 2013 8:26 PM