Forum Discussion
"The name on the security certificate is invalid..." After changing to trusted CA and updating VDs
The metabasepath values can stay as is. The OutlookAnywhere internal hostname can be changed....but this value is not the one that would be causing the issue. It's the URL's (both internal and external) that the clients use to connect to, so they are the values that need to be correct and present on the certificate. Have you got any load balancers in place? Could they be causing the issues?
So I have found some traces of the domain.local. It is still set as the FQDN for POP, IMAP and Autodiscover:
I'm not sure if I can just change the POP and IMAP FQDN to mail.domain.com without breaking it. As long as split DNS is working (which it is) this should be fine, correct?
Also, after changing the Autodiscover FQDN from domain.local to the new domain.com, Outlook went into a credential prompt loop. Any ideas why? I ended up changing it back to domain.local, because it is impacting all Outlook clients.
I'm hopeful that one of the above, or all for that matter, are the cause for this.
Thanks!
- Additional findings:
- The MessageTracking logs and the Hub Connectivity logs, are still full of the old domain.local entries. The new domain.com is not present at all.- Sometimes there will be connections made using the server's hostname. Review your internal DNS MX records if you have any.
I'm not sure why the Autodiscover FQDN did that. I only know there is generally no need to change those settings. When the Outlook client is connected to the domain it will get the autodiscover URI via the SCP record (use Get-ClientService to view the URI details), not anything in the autodiscover virtual directory- Ok I.m quite certain now that the internal Autodiscover is causing the certificate mismatch. Of course it will lookup the SCP enty first, which is domain.local. So I guess somehow I need to change the SCP entry without breaking anything or create an internal autodiscover DNS record pointing to mail.domain.com.