Exchange Active Directory Deployment Site

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

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 (192.168.0.128/29) (range: 192.168.0.129-192.168.0.134), 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!

Set-AutoDiscoverSiteScopeExchangeServers

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.

Conclusion

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