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.

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 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 ( (range:, 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.


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.

Mike O'Neill

Not applicable
My workaround is to immediately change SCP on the new server after installing a new server and point SCP to existing server/namespace:

Set-ClientAccessServer -AutoDiscoverServiceInternalUri https:///Autodiscover/Autodiscover.xml

It would be nice if MS could implement a new 'Put in production' feature. After installing a new server 'Put in production' is disabled and SCP is not returned from autodiscover requests for the new server.

After configuring (certificate etc) the new server, 'Put in production' is enabled so the new server returns SCP requests to clients.

Not applicable
Copy/paste error. Correction:"

Set-ClientAccessServer -AutoDiscoverServiceInternalUri https:///Autodiscover/Autodiscover.xml

Not applicable
The shortcoming to this approach is that it requires a site with an actual domain controller assigned to it since Exchange checks for that on setup.

For organizations that don't create Exchange servers often it probably isn't worth modifying the config of production sites/DCs just for this or to build out new DCs just for the dummy site.

I agree with Martijn that some kind of default pre-production status on new servers would be great.

Not applicable
Thx for the great ideas but having a workaround article is just like saying that this is to be expected. A larger organization will likely not allow the Exchange admin to change any settings in AD sites and services, especially on the fly. It means that

a reserve set of IP addresses for a staging environment in production will have to exist. Then when the IP address changes, I'm not sure if this would potentially cause communication issues for other Exchange servers in the same site without having to restart

their AD services. At least that is what I have faced in the past.

There are other things that have to be set on a new Exchange server in the same AD site as others, such as mail transport settings (client limits).

I third the motion that Martijn has proposed. It is simple and makes the most sense. I think it should be the other way though, default would be production, override setting during install would allow the new Exchange server to hold back from participation

until all configuration settings are completed.

Not applicable
Another option is to use my Set-AutodiscoverSCP.ps1 script. See


Not applicable
Great Article Mike!. Something that many knew, but didn't had a good reference.
Not applicable
Excellent article; I wish there were more like it. Your articles are always informative and practical.
Not applicable
Thanks for putting this good article
Not applicable
I agree with Martjin and Ecmaster76. Setting up a Deployment Site is not practicable for many customers and a "pre-production" switch would be ideal.

Anyway, unfortunately, the script from Jeff does also not cover the issue, that immediately after installing the first Exchange 2016 server, his default FQDN set on all the virtual directories, used by the client will be published.

>>See topic "list" under the section "namespaces and Active Directory Site Topologies" in the article by Ross IV.:


This situation will bring up instantly the issue that Outlook clients receives a Exchange Proxy URL with the mentioned FQDN of the new Exchange 2016 server until you change it and before you'll get time to finalyze other configuration "Exchange admin" tasks.

Today we had the problem described by Martjin here again with a customer:


It would be good if the product group checks again other variants...

An old thread I know but I'm on the cusp of 54 new servers to build (Exchange 2016 CU13) and in a 24x7 company with 200k mailboxes and hundreds of AD sites, I'm now going to cause significant popup outage again with the infamous untrusted cert.  1st thing we do post build is to update the SCP record but it's still time for hundreds of clients to be given the popup warning whilst I wait for the install to complete then our script to republish the correct Load Balancer URL... This is an appalling design here and we're 4 years down the line from the original request not to publish SCP by default yet nothing has been done .. Sigh.....................