When installing a brand new Exchange server, there are several things that you should consider. One of them is that things will go smoother if you deploy a new currently supported version of Exchange server into a live production environment by leveraging an Active Directory (AD) deployment site design option.
When you install a new Exchange server, it adds Service Connection Points (SCP’s) in records within AD and depending on your environment configuration, that new server can start answering client requests. However, since the default self-signed certificate is not trusted by clients, Outlook might start presenting certificate errors to end users. Not the best experience, and easily preventable!
When there is a valid SCP to send Autodiscover requests, the process randomly selects a server in the AD site to get requests. You can control incoming web traffic via a Load Balancer, however, the servers that GET the requests are not guaranteed to be the same servers SENDING the responses, which can cause an Outlook certificate pop-up warning.
If you try to work around this by ‘nulling out’ the AutodiscoverServiceInternalUri value on the Exchange servers that do not contain a valid trusted certificate, realize that you are not necessarily preventing the server from replying to a client to use that server. Hence, there is still a possibility of certificate warning in Outlook.
How to avoid this situation
AD is smart enough to be ‘most restrictive’ when a site subnet is defined. If you have a 192.168.0.x/24 subnet defined to an AD Site and a more restricted subnet of 192.168.0.1/32 to a different AD Site, the most restricted value is defined for that AD Site. (Note: a /32 is a single IP address, which would be enough for a single server deployment.)
Some options exist that you can leverage:
- Keep reusing the same IP to deploy a server, and then change the IP of that server once the URL’s are configured and the certificate is installed.
- Change the subnet definition in AD Sites and Services for each server you build and its’ specific IP address.
- Use a small subnet with several IP’s available, like a /29 subnet, which has 6 IP addresses (192.168.0.128/29) (range: 192.168.0.128-192.168.0.134), and setup up to 6 new Exchange servers. Then once they are fully configured, just remove the /29 subnet from AD Sites and Services, bounce the Exchange servers, reset the AutoDiscoverSiteScope values, and then they’ll answer proper values to your clients.
What AD Site is the server in?
Before you install Exchange, check to see what AD site the server is in. In PowerShell on the local Exchange server:
nltest /dsgetsite
After you install Exchange, you can change the IP or change the AD Site subnet definition, restart the server, and update the AutoDiscoverSiteScope value. Check the server again to ensure it is in the correct AD Site and also check to see if the other Exchange servers think it is in the correct AD Site by running:
Get-ExchangeServer | FT Name,Site –Autosize
And to see the Exchange AutoDiscoverSiteScope values: (pre-2016 server)
Get-ClientAccessServer | FT Name,AutoDiscoverSiteScope –Autosize
Or 2016 and above:
Get-ClientAccessService | FT Name,AutoDiscoverSiteScope –Autosize
One last step after you’ve either changed the IP of the server, or removed the AD site, you need to update the AutoDiscoverSiteScope. In PowerShell:
Set-ClientAccessService <server name> –AutoDiscoverSiteScope <name of AD Site>
You can then re-run the Get cmdlet to confirm that the values are what you need for your environment. This will help ensure that you typed the correct AD Site information in the previous cmdlet.
Conclusion
This process helps to ensure that clients will not be getting annoying pop-ups while you are installing additional Exchange servers into your production environment. It is still best to follow your companies change process and inform end users of potential notifications, but this should eliminate any unexpected Outlook interruptions.