When adding a new Exchange server to the organization the administrator may receive some complaining from the Service Desk where end-users are receiving Certificate errors on their Outlook, as shown in the figure below.
Let’s say that we have a scenario where we have 2 (two) Exchange Server 2010: TOEX14-CH01 and TOEX14-CH02 and we have just added our new Exchange Server 2013 (TOEX15-01). If we look closely at the issue on the previous image we will notice that the certificate is related to the new server.
Well, that is predictable since any new Exchange Server installation will contain self-signed certificates which are not trusted by your windows clients.
There are two ways to fix this issue: #1 we can go ahead and import/export certificates to make sure that the new server is using the same information; #2 change the Autodiscover settings on the new server to match the information that has been working in production.
I do like the second option better, why? Well, it’s a new server, you need to testing, validation and it takes time. If you configure the Autodiscover to use the current production servers you avoid any outage/issues on the client side.
If your decision was #2, here is the step-by-step: Basically compare the settings between a production server and the new one using the following cmdlet Get-ClientAccess <ServerName> | select *auto*
Now that we are ware of the configuration we just need to change the AutoDiscoverServiceInternalUri to match the production on the new server. Make sure to run an iisreset afterwards just to make sure that the refresh was done.
Voilà.. your clients will be using the production autodiscover and no more pop-ups in your clients.
Note: If you had issues with the certificates at the client level before, then this post won’t help you because your root issue is Autodiscover/Cert configuration.
Note #2: Make sure that when moving the old server you point out the new Autodiscover (if using a common DNS entry to the new servers).