We are in the process of migrating from Exchange 2010 to Exchange 2013 and have the following setup:

- 1 Ex2010 server:
  sola-exchange.addomain.local
- 3 Ex2013 servers set up in a DAG:
  sola-ex13-1.addomain.local, sola-ex13-2.addomain.local, sola-ex13-3.addomain.local
- Split DNS with all Virtual Directorys set with the same internal and external hostnames in URL:
  webmail.domain.com, oa.domain.com, eas.domain.com, autodiscover.domain.com.
- DNS round-robin for the above domain names pointing to each of the 2013 server IPs
- Wildcard certificate *.domain.com
- NTLM authentication for Outlook Anywhere, the CertPrincipleName has been set to msstd:*.domain.com

The problem:
Everything seems to work as it should, but users are presented with a certificate warning 20 or so seconds after opening Outlook.
Example: When I open Outlook I get a warning that the certificate name does not correspond with the name of the server. It tries to connect to "sola-ex13-3.addomain.local" and the certificate is the wildcard *.domain.com.
An other user might get the same warning but for an other server FQDN, sola-ex13-2.addomain.local.

This does not happen when connecting externally. Published with a TMG server.

Why does Outlook try to connect to a servers FQDN when al the virtual directory URLs are set?

This is because Outlook detected the autodiscover service connection point (SCP) in AD.

To resolve this problem,

get-clientaccessserver | set-clientaccessserver -autodiscoverserviceinternaluri https://autodiscover.domain.com/autodiscover/autodiscover.xml

• Proposed as answer by Winnie LiangMicrosoft contingent staff, Moderator Thursday, March 12, 2015 7:29 AM
• Unproposed as answer by torearre1 Thursday, March 12, 2015 8:13 AM

This is because Outlook detected the autodiscover service connection point (SCP) in AD.

To resolve this problem,

get-clientaccessserver | set-clientaccessserver -autodiscoverserviceinternaluri https://autodiscover.domain.com/autodiscover/autodiscover.xml

• Proposed as answer by Winnie LiangMicrosoft contingent staff, Moderator Thursday, March 12, 2015 7:29 AM
• Unproposed as answer by torearre1 Thursday, March 12, 2015 8:13 AM

Hi,

Please change your internal URLs to the same as your external URLs namespace. For example: Webmail.domain.com.

Set-ClientAccessServer -Identity CAS_Server_Name -AutodiscoverServiceInternalUri https://webmail.domain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "CAS_Server_Name\EWS (Default Web Site)" -InternalUrl https://webmail.domain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "CAS_Server_name\oab (Default Web Site)" -InternalUrl https://webmail.domain.com/oab

For detailed steps about it, please refer to:

https://support.microsoft.com/kb/940726?wa=wsignin1.0

Regards,

Thank you for your proposals.

Li: The AutoDiscoverServiceInternalUri has allready been set to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml for all servers.

Winnie: These are allready OK.

Get-WebServicesVirtualDirectory | fl Name,AutoDiscoverServiceInternalUri
Name                           : SOLA-EX13-2
AutoDiscoverServiceInternalUri : https://autodiscover.domain.com/Autodiscover/Autodiscover.xml
Name                           : SOLA-EX13-3
AutoDiscoverServiceInternalUri : https://autodiscover.domain.com/Autodiscover/Autodiscover.xml
Name                           : SOLA-EX13-1
AutoDiscoverServiceInternalUri : https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

Get-OabVirtualDirectory | fl Server,*Url
Server      : SOLA-EX13-2
InternalUrl : https://oa.domain.com/OAB
ExternalUrl : https://oa.domain.com/OAB
Server      : SOLA-EX13-3
InternalUrl : https://oa.domain.com/OAB
ExternalUrl : https://oa.domain.com/OAB
Server      : SOLA-EX13-1
InternalUrl : https://oa.domain.com/OAB
ExternalUrl : https://oa.domain.com/OAB

Thank you for your proposals.

Li: The AutoDiscoverServiceInternalUri has allready been set to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml for all servers.

Winnie: These are allready OK.

Get-WebServicesVirtualDirectory | fl Name,AutoDiscoverServiceInternalUri
Name                           : SOLA-EX13-2
AutoDiscoverServiceInternalUri : https://autodiscover.domain.com/Autodiscover/Autodiscover.xml
Name                           : SOLA-EX13-3
AutoDiscoverServiceInternalUri : https://autodiscover.domain.com/Autodiscover/Autodiscover.xml
Name                           : SOLA-EX13-1
AutoDiscoverServiceInternalUri : https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

Get-OabVirtualDirectory | fl Server,*Url
Server      : SOLA-EX13-2
InternalUrl : https://oa.domain.com/OAB
ExternalUrl : https://oa.domain.com/OAB
Server      : SOLA-EX13-3
InternalUrl : https://oa.domain.com/OAB
ExternalUrl : https://oa.domain.com/OAB
Server      : SOLA-EX13-1
InternalUrl : https://oa.domain.com/OAB
ExternalUrl : https://oa.domain.com/OAB

Hi,

Sorry for my delay. Has the issue been resolved?

Please run the following command to get detailed certificate information in your Exchange server:

Get-ExchangeCertificate | fl

In client side, pease run the Test E-mail AutoConfiguration tool to confirm which service is used with the mismatch namespace:

Open Outlook - press CTRL key - right click on the Outlook icon from right bottom corner taskbar - Test Email AutoConfiguration. Put your email address - uncheck use guessmart and secure guessmart authentication - click Test to check your Autodiscover service. Collect the inofrmation in the Results tab.

Regards,

Hi,

Any updates?

Regards,

I'm battling this exact issue.

I'm curious, do you have the EXCH outlook provider CertPrincipal name set?

Get-OutlookProvider

It is typical with wildcard certs to set the EXPR provider. But I'm finding I may also need to set the EXCH provider.

Set-OutlookProvider EXCH -CertPrincipalName msstd:*.domain.com

Hi,

Sorry for the late reply!

I'm not sure why, but this problem has gradually resolved itself. Must have been because of other changes/fixes we have had to perform during our migration.

We are using a wildcard cert, and I had only set the EXPR provider with CertPrincipalName msstd:*.domain.com.
A few days ago we had problems with some Outlook 2007/2010 users after we moved them to Exchange 2013.
I had noticed that the OA settings in Outlook was AutoDiscovered to msstd:oa.domain.com, but it worked fine both internal and external with Outlook 2010/2013 during testing.
I found that manually changing to msstd:*.domain.com on the affected clients resolved the issue before AutoDiscover kicked in again, after som Google-ing I found that also the EXCH provider needs to be set to msstd:*.domain.com as Sferrero writes. This made AutoDiscover set msstd:*.domain.com.

Hope this is useful to some even though I'm not sure what our initial problem was and how it got fixed, the problem disappered before I set the EXCH provider

• Edited by torearre1 1 hour 27 minutes ago