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.
Whenever a new Exchange server that holds the Client Access Server Role, or any Exchange 2016 server, is installed the setup process adds a new Service Connection Point (SCP) record within Active Directory. SCP records are used by internal domain joined clients and applications to locate the Autodiscover service. Depending on your environment’s configuration, there is a chance clients may see this new SCP record and begin sending Autodiscover requests directly to the new server before you have had a chance to configure it. However, since the default self-signed certificate is not trusted by clients, then any client contacting this new server will start presenting certificate errors to end users. This is not the best experience, and it is easily preventable!
To prevent clients from sending Autodiscover requests directly to this new server you may already be “nulling out” the new SCP record’s AutodiscoverServiceInternalUri value or setting it to your friendly load balanced URL. This step will ensure clients will either not attempt to use the SCP at all, or if they do they will be sent to your load balancer with valid certificates already in place. While either method prevents clients from sending Autodiscover requests directly to the new server until you have had a chance to configure it, you are not out of the woods just yet. Clients sending Autodiscover requests to a server is only one half of the Autodiscover equation. We must also consider how Autodiscover responses are generated before being sent back to the clients.
It is important to understand the server receiving the Autodiscover request not simply use its own settings to create the response. Instead, the receiving server identifies what version mailbox the user has, identifies what Active Directory site the user’s mailbox is currently mounted in, identifies information about the client being used, and identifies whether or not the user’s mailbox site is Internet facing. Once the receiving server has all of the information it needs it will then determine where to obtain the values it will use to create the Autodiscover response. Some of the values will be chosen from a random server in the same AD site as the user’s mailbox, and if necessary due to the mailbox site being non-Internet facing other values will be from a random server in the AD site with the least cost path that is Internet facing. The receiving server then compiles the values and returns them in the form of a single Autodiscover response to the client. If your brand new Exchange server resides in the same AD site as the user’s mailbox or the chosen Internet facing site, then your clients have a chance of seeing certificate popups due to your new server’s virtual directories and Outlook Anywhere configuration still having the default FQDN values in place. For example if Outlook where to attempt to download your Offline Address Book using the new server’s default setting of https://exch2016-01.corp.contoso.com/oaby, then the client would see a certificate prompt.
With this understanding we now should understand there are two things required to prevent a new server from introducing certificate warnings in an environment. First, we must prevent the new server from getting any requests directly from clients. Second, we must prevent this server’s default values from being used in a response generated by any other Client Access Servers (or Exchange 2016 servers) that receives an Autodiscover request.
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:
Before you install Exchange, check to see what AD site the server is in. In PowerShell on the local Exchange server:
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.