When installing a new Exchange server (2013/2016/2019) in an existing environment, Microsoft recommends installing this new Exchange server in a separate Active Directory site, configure the server there and then move the server to its production Active Directory site.
The reason for this is Outlook and the Service Connection Point (SCP) in Active Directory. Somewhere during the installation process a new SCP is created in Active Directory, but when created it is not configured and points to the FQDN of the Exchange server instead of the more general Autodiscover.contoso.com/Autodiscover/Autodiscover.xml URL. When an Outlook client accidentally discovers this unconfigured SCP it will try to connect to the new server instead of the Autodiscover FQDN which will result in a certificate warning message similar to the following:
To avoid this, the SCP should be configured as soon as it is created in Active Directory (and this is during setup itself).
Tony Murray, also an MVP, has written a PowerShell script (Set-AutodiscoverSCPValue.ps1) that will check the existence of the Exchange server object in Active Directory, and when it is created by the Exchange setup application, it immediately sets the correct Autodiscover value in its SCP.
When you run the script it will check every 5 seconds (time is configurable) for the newly created server object, and when it finds it, it will set the correct value as shown in the following screenshot:
From this moment on Outlook client can safely discover this SCP record, and it will be automatically connected to the correct Autodiscover URL and therefore the SSL Certificate warning will not appear (assuming the original servers are configured correctly of course).
More information and download – https://gallery.technet.microsoft.com/office/set-autodiscoverserviceinte-3930e163
Jaap Wesselius 
Its better than creating a whole new AD site (with domain controller offcourse) and installing Exchange in the new AD site. But changing the SCP to the correct autodiscover URL is one thing but what about the trusted certificate (with autodisciver URL) that need to be binded to IIS service. WIth this script the SCP is changed but a user can potentially land on the new Exchange server with the correct SCP (autodiscover URL) but the self signed cert is still binded to IIS service, resulting in a certificate warning.
LikeLike
If you have configured your name resolution well and use a load balancer, the outlook client will connect to the VIP (information from SCP) and then be connected to the proper existing Exchange servers. How can these outlook clients potentially land on the new Exchange server?
LikeLike
+1 you are correct, the new server is not in the NLB pool offcourse. Sorry did not had my coffee yet 😦 This is actually a nice Microsoft Exchange exam question btw.
LikeLike
Hello Jaap,
Is this script still available somewhere, since gallery was decommissioned?
Keep up the good work!
Kind regards,
Bruno
LikeLike
Hi Bruno,
I have been looking in the past for a newer version of this script, also tried to contact Tony Murray for this but no luck. A friend of mine has written an improved version, but I have to search for it tomorrow or Thursday. Send an email to ‘mail at jaapwesselius.com’ as a reminder and I’ll get back to you.
LikeLiked by 1 person