We recently had a new certificate issued for our Exchange environment, removing the Subject Alternative Name entries which were for '.local' domains.

We changed all our virtual directories to use our public FQDN for both internal and external mapping (we have split DNS set up to resolve the FQDN to local addresses from within our local network).

After installing the new certificate we realized (because of the certificate errors being received by clients) that the AutoDiscoverServiceInternalUri was still set to the old [hostname].[domain].local/autodiscover/autodiscover.xml location.  So I then ran the Set-ClientAccessServer -Identity [server] -AutoDiscoverServiceInternalUri" https://[full public FQDN]/autodiscover/autodiscover.xml" command, and can now verify that the AutoDiscoverServiceInternalUri is set to the correct path.

Even after making these changes Outlook clients have continued to receive the same certificate error, showing that Outlook is still trying to connect to the old [hostname].[domain].local address and indicating that the name on the security certificate is invalid or does not match the name of the site.  Although if we recreate a new Outlook profile they do not get the error, so I can only assume that all existing Outlook profiles are using some cached information.

I've run a Test E-Mail AutoConfiguration, and it does show that AutoConfiguration is connecting to the correct FQDN version of the Autodiscover file.

I have manually updated the Offline Address Book, and manually downloaded the address book on the client, but that has not resolved the problem.

Is there something I have missed?  Is there some other step that needs to be performed to get all clients to use the new AutoDiscoverServiceInternalUri and forget about all references to the old one?

Look at the Exchange Web Services and Offline Address Book URLs, as well as Outlook Anywhere.  Check OWA, ECP and ActiveSync while you're at it.

Would you please check the outlook provider...

Run Get-OutlookProvider | FL to check the value of CertPrincipalName. The outlook client should be match to this setting.

Use the Set-OutlookProvider cmdlet to set specific global settings using the msExchOutlookProvider attribute on the msExchAutoDiscoverConfig object in Active Directory.

HI

Please change the Internal URL for all the virtual directories from '.local domain to internet facing domain name.

Post the changes check the same on outlook end.

Also check the DNS record for Auto discover host,it should be in '.local and .com' format.

-

Hello

Autodiscover xml is downloaded during the outlook first launch and configuration. IT continue to use the same name due to cache outlook mode. This is limited to outlook only. Try to create a DNS entry of old Autodiscover url to new one.

you cal also try to take the outlook in online mode and take back to cache mode then let us know if this is gone.

Hi,

Please run the below command to check the OA settings:

Get-OutlookAnywhere | fl Identity,*host*

You can refer to the below article to change those virtual directories URL:

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

Make sure you have correct DNS records for autodiscover services and public FQDN.

Regards,

David 

Hi Ed.  All the virtual Directory URLs have been set as per our full external (and also internally resolvable, split-DNS) FQDN.  This was done several weeks before we changed the certificate.

Hi Murali.  All the virtual Directory URLs have been set as per our full external (and also internally resolvable, split-DNS) FQDN.  This was done several weeks before we changed the certificate.

I'm not sure what you mean when you say that the DNS record for Autodiscover should be in .local and .com format.  Our external DNS has it in .com format (and everything works fine for external clients).  Our internal DNS does not have a zone for autodiscover at all, but internal clients shouldn't need DNS should they - wont they resolve to autodiscover through the SCP?

Thanks Prem. Taking it out of cached mode does not make a difference.  The error still occurs when in online mode, and continues to occur when changing back to cached mode.

HI Mahmoud,

the CertPrincipalName is blank on the CAS servers, which I understand means it will use the ExternalHostname for the Certificate Principal Name. And when checking the properties in the client it is set with the "only connect to proxy servers that have this principal name in the certificate" set to "msstd:<externalhostname>", so all that seems to be in order. 

Hi David,

I have all the properties set up per the details in the link you provided, and I have recycled the application pools on all the CAS servers.  But still no good :(