I have a client with Exchange2010 on-premises.
For some reason they have a public certificate without SAN, and it doesn't mention the host 'AutoDiscover' - it is named workplace.domain.co.uk instead. It is not a viable solution to replace the existing public cert with a SAN cert.
AutoDiscoverServiceInternalUri on their CAS points to https://workplace.domain.co.uk/Autodiscover/Autodiscover.xml and so does the SCP's serviceBindingInformation in AD.
Get-AutodiscoverVirtualDirectory indicates that InternalUrl and ExternalUrl are also both set to the same URL above already: I have not modified the existing setup despite the comments in https://blogs.technet.microsoft.com/rmilne/2013/04/02/busting-the-set-autodiscovervirtualdirectory-myth/
All other Exchange virtual directories are also pointing internalurl to https://workplace.domain.co.uk/EXCH.Service
The client has a splitbrain forward zone in DNS that has an A record for workplace.domain.co.uk with the IP address of CAS.ADdomain.local.... it does NOT have a record for domain.co.uk or autodiscover.domain.co.uk
There are also no SRV records for autodiscover in the internal or external DNS zones.
... might this be necessary, despite the presence of the SCP in AD ??
On the client, Test E-Mail AutoConfiguration logs progress through testing SMTPdomain/autodiscover..., then autodiscover.smtpdomain/autodiscover...
Test-OutlookWebServices is mostly delighted with the setup, except for the error:
" The certificate for the URL https://CAS.ADdomain.local/Autodiscover/Autodiscover.xml is incorrect. For SSL
to work, the certificate needs to have a subject of host.ADdomain.local, but the subject that was found is workplace.domain.co.uk. Consider correcting service discovery, or installing a correct SSL certificate."
I am not sure where it is finding the internal FQDN - any suggestions welcome !
Now I have worked through http://support.microsoft.com/kb/2783881 and kb/2480582 and have added the following empty values to HKCU\Software\Microsoft\Office\15.0\Outlook\AutoDiscover\RedirectServers
autodiscover.domain.co.uk REG_SZ
workplace.domain.co.uk REG_SZ
...which makes no difference.
I have enabled logging in Outlook on the misbehaving client but the OLKDISC.log is not created - just the .ETL files that OL logging has always provided.
https://support.microsoft.com/en-gb/kb/2772058 and kb/940881 have been of no use.
The key problem is that only 1 Outlook 2013 client is getting the regular cert-mismatch warnings... no other clients do. Typically, it is a vip experiencing this problem.
What have I missed ?
regards
Nick
Ignite a fire and a man is warm for a night: ignite a man, and he is warm for the rest of his life.