How to add an Exchange Server with AutoDiscover SCP disabled or hidden by default

I'm building some new Exchange 2019 servers in my environment and do not want clients to immediately use their AutoDiscover service connection points (SCP) that get created in Active Directory during installation. We should be able to update the default InternalUrl/ExternalUrl values and test before these become active. What is the best way to hide, block, or disable the default SCP until I am ready to use them?

Our options appear to be:

• Update the URL values as quickly as possible after the installation completes.

Or run a looping script that looks for the creation of the SCP during installation, and performs an action immediately, such as:

• Remove "Domain Users" read permissions when it is found (or add a 'deny', but 'deny' ACEs...).
• Set the AutoDiscoverSiteScope attribute to a non-existent AD site as quickly as possible after the installation completes so the new one is not considered authoritative for an AD site.
• Set the IsOutOfService attribute to $true.

Or something else to make them start out in a 'disabled' or 'out of service' state?

Solution 1:

Looking at the Exchange Team Blog (Exchange Active Directory Deployment Site), Microsoft recommend creating a deployment site in Active Directory.

Basically, when Outlook searches AD for the list of SCPs, it will look at the keywords attribute for each one; in particular, "Site=MySite" gets a priority of 1, no "Site=" value gets a priority of 2, and "Site=OtherSite" gets a priority of 3. (I'm using MySite and OtherSite as placeholders for actual site names.)

So, as long as you have an existing SCP which matches your clients' site (priority 1), you can add a new SCP for a different site (priority 3) and Outlook will ignore it. That gives you time to configure the new Exchange server before end users actually connect to it, and therefore they won't get certificate warnings etc.

So, you can set up a small subnet (using AD Sites and Services) and put the new Exchange servers in there temporarily. However, note that you will need to have a domain controller in that site. If that's not practical, the only other option is what joyceshen suggested, i.e. do this out of hours and try to update the URI as quickly as possible, but that will cause some disruption.

After you move the new Exchange server to the real site, you will need to update the AutoDiscoverSiteScope property of the client access service:

Set-ClientAccessService -Identity "MyServer" -AutoDiscoverSiteScope "foobar"