Problem: We recently renewed an expiring SSL certificate for Exchange 2010 (removed internal fqdns) and now Outlook clients get SSL security alert when launched.
Due to an 11/1/15 expiration of using internal FQDNs (our domain ends in .local), we've changed the UCC SAN cert to only include:
We setup split dns to ensure the 2 external FQDNs above can be resolved internally, then ran a bunch of powershell SET commands so our Exchange environemnt will use same URi's for both internal and external.
Everything is working well, EXCEPT...
Our Outlook 2010 and 2013 clients get an ssl security alert ONCE when first opening Outlook.
The alert has the INTERNAL fqdn of our CAS server on it
Since that is no longer on the new UCC SAN cert, the security alert pops up.
Some part of the Outlook profile (maybe cached) is still pointing the Outlook client to CAS server's internal FQDN vs. the new public FQDN
Clicking yes makes it go away for duration of outlook being open. Of course, it will become very annoying to end users after a while.
Every article I've researched says the same thing...make sure none of the intrenal URis point to old way (internal FQDN of CAS server). I've triple checked that.
Seems only reliable way to make this go away is rebuilding local outlook profile which I want to avoid (100 users). Oddly, one Outlook 2013 client seems to have had alert stop showing up, but not others in my test pool.
Troubleshooting Done So Far
Again, triple checked all commands launched on CAS server - the internal URi definitely matches external URi in following commands below. Each of these attributes previously showed the internal FQDN of the CAS but not anymore. Now all show mail.example.com:
*Using CAS_hostname for examples below:
Get-ClientAccessServer -Identity CAS_hostname | fl AutodiscoverServiceInternalUri
Get-WebServicesVirtualDirectory -Identity "CAS_hostname\EWS (Default Web Site)" | fl InternalUrl
Get-OabVirtualDirectory -Identity "CAS_hostname\oab (Default Web Site)" | fl InternalUrl
Get-ActiveSyncVirtualDirectory -Identity "CAS_hostname\Microsoft-Server-ActiveSync (DefaultWeb Site)" | fl InternalUrl
Get-OwaVirtualDirectory -Identity "CAS_hostname\owa (Default Web Site)" | fl InternalUrl
Get-EcpVirtualDirectory -Identity "CAS_hostname\ecp (Default Web Site)" | fl InternalUrl
The only item that was not changed is the OutlookAnywhere attribute because internalHostname was blank before we converted:
Get-OutlookAnywhere -Identity "HostName\Rpc (Default Web Site)" | fl InternalHostname, InternalClientsRequireSsl
I've also checked the SCP using AD Sites & Services and it correctly shows the internal URi is our pubilc FQDN (mail.example.com)
Most articles claim this is due to AutodiscoverServiceInternalUri still being set to the internal CAS FQDN, but ours is definitely set correctly along with all other attributes.
All internal Outlook clients are using Cached Exchange Mode and connect fine. They just have the annoying single security alert.
I've tried a bunch of things including the Outlook "Test email auto configuration" which comes back with the correct public FQDNs and no mention of the CAS server's true internal FQDN.
I've also tried going to Outlook account settings and choosing repair to see if it will run refresh setup and detect changes completely without rebuilding the entire profile. This seemed promising but did not work.
I've tried clearing SSL state on local PC and rebooting - does not help.
Does anyone know how I can get Outlook profiles to stop showing this prompt at launch? It makes no sense that they still are looking at CAS internal FQDN for something...