Exchange Active Directory Deployment Site

Published Nov 18 2015 12:28 PM 72K Views

Note: This article received a major revision on 12/4/2019.

When installing a brand-new Exchange server, there are several things that you should consider. One of them is that the process will go smoother if you deploy a new Exchange server into a live production environment by leveraging an Active Directory (AD) deployment site design option.

There has been some confusion on what is required for a deployment site to work properly and therefore this information has been updated. Before we get into the prerequisites for a successful deployment site, let’s review how Autodiscover works with Outlook. If you want a deeper dive, here is a good white paper on the subject. Don’t be alarmed by the Exchange 2007 reference, the core functionality of Autodiscover has remained essentially unchanged and everything in the document is still accurate. Newer versions of Exchange have some added Autodiscover functionality but none of that effects this deployment site discussion.

When Outlook wants to make an Autodiscover query, it first contacts Active Directory (AD) looking for all SCP (Service Connection Point) objects. Every time a new Exchange server is installed, it is going to create a new SCP object that contains two pieces of information, the serviceBindingInformation attribute and the keywords attribute. The serviceBindingInformation attribute is a URL that points to either the Exchange server that created the SCP object or what URL is set using the Set-ClientAccessService command with the –AutoDiscoverServiceInternalUri attribute. The keywords attribute is a list of AD Sites that the SCP object is authoritative for. After Outlook obtains and enumerates the instances of the Autodiscover service, the client connects to the first Client Access service in the enumerated and sorted list that has a keywords match to its own site. If Outlook can’t find its own site in the list of SCP objects keywords attributes, it will use the newest SCP object created. Which just happens to be the SCP object of that shiny new Exchange server you just installed.

It is important to understand the server receiving the Autodiscover request does 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. If your brand new Exchange server resides in the same AD site as the user’s mailbox, the chosen Internet facing site, or is the newest SCP record and the Outlook client is not in a defined site then your clients have a chance of seeing certificate popups due to the new server’s virtual directories and Outlook Anywhere configuration still having the default FQDN values in place.

With this understanding of why Outlook finds that new Exchange server, it is easier to explain how to fix it. Often, there are many AD sites defined in AD that are not covered by an AutoDiscoverSiteScope. And those sites can contain Outlook clients. So, whenever you install a new Exchange server, all the Outlook clients associated with a site that is not part of an AutoDiscoverSiteScope will use the SCP record of the newest Exchange server. This will cause Outlook certificate prompts as well as incorrect URLs being given out for other Exchange services. When incorrect URLs are given, it will cause connection failures to a user’s mailbox.

With this understanding, there are three tasks required to prevent a new server from introducing certificate warnings and incorrect URLs to end users within an environment. First, the new server must be prevented from getting any requests directly from clients. Second, the new server’s default values must be prevented from being used in a response generated by any other Client Access Servers that receive an Autodiscover request. Third, all other AD sites must be defined in AutoDiscoverSiteScope values of Exchange servers.

How to avoid this situation

You need to create a “deployment” AD site. 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.)

Here are choices when deploying new Exchange servers:

  • Keep reusing the same IP to deploy an Exchange 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, a /29 subnet for example, which has 6 IP addresses ( (range:, and setup to 5 new Exchange servers already available in the deployment site. 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.

Reminder, you’ll also need a Domain Controller (DC) in the same site as the new Exchange server(s) for the installation to work properly for each of these scenarios.

AutoDiscoverSiteScope for an organization

Now it is clear how Outlook finds that new server and that the AutoDiscoverSiteScope needs to be set, it is now able to be corrected in all AD sites that must be defined in the AutoDiscoverSiteScope per Exchange server. It can be a daunting task to find all your AD sites and make sure they are associated with an AutoDiscoverSiteScope for every Exchange server in an organization. Is there a solution available?

Yes, there is a fully functional solution to solve this AutoDiscoverSiteScope issue. In the Exchange_AddIn PowerShell module, the Set-AutoDiscoverSiteScopeExchangeServers function is available. (Didn’t want the noun to be confused with any other cmdlet, hence the long name.) At the easiest step, you can just run this function in an Exchange organization, it’ll scan all AD sites, exclude any deployment sites (that is a parameter that can be modified), and assign the rest of the AD sites to every Exchange server in the environment. This would be the easiest process for most customers.

Install the PowerShell module by running this code at a PowerShell elevated prompt:


Install-Module –Name Exchange_AddIn


If you set every single Exchange server, with the scope of every single AD site (minus the deployment one(s)), then when you stand up a new Exchange server (in a deployment site), that Exchange server will be ignored by Outlook clients. Since the AD sites are scoped correctly into the Exchange/AD forest, the clients will get a proper answer from a properly provisioned server and thus not fallback to the newest SCP record. Problem solved!




By using no parameters, this will set all AD sites in the forest, excluding anyone(s) with a search value of *deploy*, to every Exchange server AutodiscoverSiteScope value in the organization.

This line of code below will set all AD Sites in the forest, excluding the AD site of test, to all Exchange servers AutodiscoverSiteScope setting.


Set-AutoDiscoverSiteScopeExchangeServers -DeployADSiteExclusion 'test'


But what if you have a very large, complex environment? Fear not, the function can handle that request also. A bit more work on your part, but that’s a good thing. You can use the Export-CSVAllADSites function that creates a CSV file with 4 columns of data, one of them fully populated with AD sites in the AD forest. The other three columns, you must fill out: Identity, RegionForServers, and RegionForClients.

  • Identity: This is the Exchange server NETBIOS/FQDN names that the PowerShell code will read in, to set on specific servers.
  • RegionForServers: This column will be the regions that you want to assign Exchange servers to cover the Outlook client requests.
  • RegionForClients: This column needs to match the server regions as being defined on where the client AD sites reside, to which servers will handle the request.

Example CSV file:





































































Once this CSV file is filled out, you can import it into the Set-AutoDiscoverSiteScopeExchangeServers and it’ll set the Exchange severs, to the region that you define, to cover the Outlook clients closest to the Exchange serves, in the data center that makes sense for your organization. Therefore, any Outlook client, calling into a defined Exchange Autodiscover site scoped server, will avoid any new Exchange server SCP objects, since the AD site the client is claiming to be in, is defined in the Exchange servers. Problem solved. No more certificate prompts from Outlook clients when standing up new Exchange server where the services are not fully configured yet.

The code for importing a file named ADSiteInfo.csv from the c:\temp folder:


Set-AutoDiscoverSiteScopeExchangeServers -ImportFile C:\temp\ADSiteInfo.csv


The function has risk mitigation options built in, so you can run both or either of the -whatif switch and/or the -confirm parameter switches, before you blast this into production. With this CSV import, it is an all or nothing option. All servers listed, will use the regional values you set, by design. If there are any values already set, this function resets them to what you want. But this is what you need, as AD sites come and go, you wouldn’t want to retain older out of date values (or previously mis-typed ones), hence the reason you need to be careful and conscience with the values you put into the CSV file.

Even if you assign an AD site to a region that the mailbox is not optimal with bandwidth to attach to, by at least having them defined, the clients will get a proper response and ignore the non-configured SCP objects, since the AD site scope is properly answering a valid AD Site of where the client resides. As mentioned above, the Outlook client will search the keywords values of the list of Exchange server(s) in its’ own site, if it exists, else it uses AD Site link cost values to then get to the closest Exchange server. The key we are talking about here is, IF you don’t have all AD Sites listed for Exchange servers to answer, THEN you have a potential for certificate issues when deploying new Exchange servers.

New Exchange Server installation process.

Before performing a new Exchange Server installation, check to see what AD site the server Operating System thinks it is in. In PowerShell on the local Exchange server run:

nltest /dsgetsite


Once the Exchange Server application is installed, the IP can be changed 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 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: (2010+)

Get-ClientAccessServer | FT Name,AutoDiscoverSiteScope –Autosize

Or 2013+ versions:

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.

If you are using the CSV file option to maintain records of Exchange servers, don’t forget to update it with servers you add or remove from the organization. You can re-run the Set-AutoDiscoverSiteScopeExchangeServers function whenever you want, just to ensure all servers are correct. Use reasonable judgment on how often to update the values, usually when AD sites are added/removed, or Exchange servers are added/removed.


There you go, a detailed explanation on how to fix this issue. Yes it sounds like more work, yes you need to be aware of any AD site updates, but it will solve your new Exchange server installs as the Outlook clients will have fully defined Autodiscover site scope values, excluded new Exchange server installs, and therefore will not have any unexpected interruptions presented to your end users.

Mike O'Neill and David Fife

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...

Senior Member

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..................... 

Occasional Contributor
We are just about to implement Exchange 2016 (Current exchange environment is Exchange 2010) If we were to follow the the method of the article - do we need an additional Domain Controller for each Exchange Active Directory Deployment Site?
Occasional Visitor

I do not understand why it is not possible to put an option to the setup which configures the scp correctly. This is a MUST HAVE feature in my eyes since Exchange 2007. The documenation ist just an workaround.


Excellent work

Senior Member

I really appreciate you taking the time to clarifying the process required and recognising it's not easy to install a new server unless the AD Sites is set up correctly... I look forward to posting about how we corrected our own sites collection in the near year as it's definitely foo bar'd at the moment given we light up the helpdesk like a Xmas tree every time we install a new server..

Senior Member

The even easier solution is to delete the serviceBindingInformation SCP information for the new server using adsiedit.msc before the server first boots its IIS services, then from the get go it wont be a problem. You can always add it back in with the proper URL once you've put the certificates on the box. This way you don't need to do any of the above.

Occasional Visitor
My solution is to enable firewall on the new server and explicitly block HTTPS (TCP/443) for all profiles. This prevents the clients to be able to connect to the autodiscover service (which causes the man issue). After the server is installed, on can just set the right service endpoint settings, wait for them to be applied and then remove the firewall block for HTTPS.
Senior Member

I deploy a certificate with the server FQDN to the server before installing Exchange which will then be bound to IIS by setup. As the customer usually has an Enterprise PKI where we can do this effortlessly.

Thus clients will have no trust issue, and then within minutes after setup i can set all the URLs to the Loadbalancer values.

Version history
Last update:
‎Dec 04 2019 09:49 AM
Updated by: