Just a quick note to self, and hopefully it might help someone out there.
People working with Exchange 2007 have most likely stumbled over the problem with Outlook connecting trough Outlook anywhere, where the Common name (first name in the certificate) does not match the server name used in the RPC/HTTP configuration.
This usually results in connectivity issues with Outlook Anywhere (for example password prompts that will not apply the correct username and password).
An example of this configuration is if you use a wildcard certificate which has *.domain.com as the subject name in the certificate. If you have configured mail.domain.com as outlook anywhere server and all other settings as default, the Outlook client will get this configuration
The problem here is that the CertPrincipalName msstd:mail.domain.com does not match the common name in the certificate that is *.mail.com. So in order to fix this we usually runs the command Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.domain.com. This force the CertPrincipalName to be msstd:*.domain com which match common name. Voila! For more information about the OutlookProvider settings and how to use it, read: http://blogs.technet.com/b/exchange/archive/2008/09/29/3406352.aspx
Now back to Exchange 2013. When introducing Exchange 2013 which only relies Outlook Anywhere (MAPI is no more:) ), the CertPrincipalName gets important on internally connected Outlook clients as well. This seems to only be a problem with computers running Windows XP (and Office 2010 in my example).
A customer of my told me that all his XP machines (luckily it was only a few XP machine left) was asking for username and password, and was not accepting the credentials. The Windows 7 machines was using SSO as i used Kerberos as authentication working perfect.
The XP machine was also working when they was connected externally. Outlook anywhere is using the same URL internally and externally, which is outlook.domain.com, but externally is published with TMG, and internally Outlook clients are going directly to Exchange server.
I did know that the TMG server had public certificate with outlook.domain.com as common name. But the Exchange server, which has a certificate from internal CA server, had servers FQDN as common name and outlook.mail.com only as SAN name !!
Since I don’t want to have FQDN server as CertPrincipalName, I requested a new certificate from internal CA server with outlook.domain.com as common name, and servers FQDN and netbios name in the SAN fields.
And guess what, suddenly both XP clients and W7 clients could connect both internally and externally:)