Jan 18 2023 07:18 PM - edited Jan 18 2023 07:22 PM
Hello,
This is with Exchange 2019.
after changing the virtual directories to mail.domain.com (from mail.domain.local) and applying the appropriate certificate, when starting Outlook, the following message pops up (the blacked out part is still showing the old mail.domain.local instead of the mail.domain.com):
Exactly what is described here: https://www.youtube.com/watch?v=arhOzkEAog4
However, the solution displayed in the Youtube video did not help in this situation.
Clicking 'Yes' will open Outlook and email works as usual.
This error has also briefly made an appearence, though it has only happened the first 5-10 minutes after making the changes, so probably something had to update in the background first:
Not sure anymore what else to do to resolve the issue in the first screenshot. Any help much welcome! (thinking somewhere is still a wrong URL set...RPC maybe...Outlook anywhere...but I checked all those),
The new cert common name: mail.domain .com.
SANs: autodiscover.mail.com, domain.com, mail.domain.com
Cheers,
Jan 18 2023 10:26 PM
Jan 19 2023 07:28 AM
Jan 22 2023 03:58 PM
Feb 08 2023 09:29 AM - edited Feb 08 2023 09:33 AM
Ok so after updating all the virtual directories to the new fqdn mail.domain.com, I found that a reference to the old fqdn domain.local entry still exists in the following places (mostly the MetabasePath). The one's I'm assuming can stay, are in green and the ones I'm assuming need to be updated to the new mail.domain.com manually, are in red:
Get-ClientAccessService:
Fqdn: old.domain.local < manually change this to mail.domain.com?
AutodiscoverServiceInternalUri: https://domain.local/autodiscover/autodiscover.xml < this can stay?
Get-OutlookAnywhere:
InternalHostname: domain.local < manually change this to mail.domain.com?
MetabasePath: IIS://domain.local/W3SVC/1/ROOT/Rpc < this can stay?
Get-OwaVirtualDirectory:
MetabasePath: IIS://domain.local/W3SVC/1/ROOT/owa < this can stay?
Get-ActiveSyncVirtualDirectory:
MetabasePath: IIS://domain.local/W3SVC/1/ROOT/Microsoft-Server-ActiveSync < this can stay?
Get-AutodiscoverVirtualDirectory:
MetabasePath: IIS://domain.local/W3SVC/1/ROOT/Autodiscover < this can stay?
Get-EcpVirtualDirectory:
MetabasePath: IIS://domain.local/W3SVC/1/ROOT/Ecp < this can stay?
Get-OabVirtualDirectory:
MetabasePath: IIS://domain.local/W3SVC/1/ROOT/OAB < this can stay?
Get-PowerhShellVirtualDirectory:
MetabasePath: IIS://domain.local/W3SVC/1/ROOT/PowerShell < this can stay?
Get-WebServicesVirtualDirectory:
MetabasePath: IIS://domain.local/W3SVC/1/ROOT/EWS < this can stay?
In addition to the above, all of the receive connectors still have the domain.local configured as the FQDN (HELO or EHLO response).
Feb 08 2023 05:08 PM - edited Feb 08 2023 05:10 PM
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?
Feb 25 2023 02:10 PM - edited Feb 25 2023 02:11 PM
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!
Feb 28 2023 03:00 PM
Feb 28 2023 05:34 PM
Mar 01 2023 10:01 AM
Mar 02 2023 10:53 AM
Mar 05 2023 08:10 PM
Mar 24 2023 12:36 PM