When installing new Exchange 2016 servers, for example for migration, you need to proceed with caution. Exchange servers feel compelled to respond to client requests immediately after installation.
The background is as follows:
As soon as a new Exchange Server is installed, SCP (Service Connection Point) entries are also created in the Active Directory. The SCP entries are in turn used by the clients to find and call Autodiscover. As soon as a client addresses the newly installed Exchange Server, it receives a certificate warning and attempts to talk to the Exchange Server that has not yet been fully configured. This behavior results from the fact that existing and new Exchange Servers are located within the same Active Directory location. In this example, it is the location "Default-First-Site-Name":
There are several ways to get around this problem, although they differ in terms of effort and requirements.
Solution 1: Deployment site for frequent Exchange installations
This solution is suitable for all those who need to install many Exchange servers, i.e. large companies or companies with many distributed locations. This solution requires some preparation, but is very reliable.
After creating the new location, it looks something like this:
The IPs 172.16.100.129 to 172.16.100.134 are now permitted in this subnet (remember: do not use network address .128 and broadcast address .135 for hosts).
But: As you can see from the screenshot above, there is no domain controller in the new location. However, a domain controller is required in the location for the Exchange installation. Exchange checks whether a domain controller is available at the location during the readiness check before the installation; if this is not the case, the following error message appears:
Error:
Problem checking the status of Active Directory: No domain controllers are available for the domain 'frankysweb' and the site 'ExchangeInstall'. See the Exchange setup log for more information on this error.
Further information can be found at: http://technet.microsoft.com/library(EXCHG.160)/ms.exch.setupreadiness.AdInitErrorRule.aspxError:
Active Directory does not exist or no connection can be established.
Further information can be found at: http://technet.microsoft.com/library(EXCHG.160)/ms.exch.setupreadiness.CannotAccessAD.aspx
Anyone who frequently installs Exchange servers must therefore install a domain controller within the "ExchangeInstall" site. This solution is therefore only worthwhile if new Exchange servers are installed frequently.
The IP address of the Exchange server must then be set to an IP address within the "ExchangeInstall" location:
The following command can be used to check in which location the Exchange Server is located
nltest /dsgetsite
Exchange 2016 can now be installed and configured as usual without clients using the server for requests.
As soon as the configuration is complete and the server is to be put into production, the IP address must be changed again. The DNS entries (forward and reverse) should also be checked.
Finally, the following command must be executed in the Exchange Management Shell:
Set-ClientAccessService SERVERNAME -AutoDiscoverSiteScope "Name of the final AD site"
So if the server FWEX1 is back in the "Default-First-Site-Name" location, the command is:
Set-ClientAccessService FWEX1 -AutoDiscoverSiteScope "Default-First-Site-Name"
Solution 2: Customize SCP (Service Connection Points)
Another solution is to customize the SCP entries themselves. This procedure is particularly suitable if only a few servers or only a single server is to be installed.
Exchange Server is installed here as normal, without having to make any preparations beforehand (see solution 1). The only thing that matters here is the timing.
While the installation is running, the "Active Directory locations and services" console can be opened. "Show service nodes" must be selected in the view settings:
During the Exchange installation, you can then navigate to the "Protocols" object:
During the Exchange installation, from step 14 of 15, the SCP entry for Autodiscover is created:
As soon as the entry is visible (don't forget to press F5), the SCP object can be edited:
The values for "serviceBindingInformation" and the location under "keywords" can be removed here:
Now Exchange Server can be configured, but please do not forget to add the corresponding entries again after the configuration.
This option does not solve all problems, but at least the
Solution 3: Configure quickly
For small organizations or only one Exchange server to be migrated, you can also simply use the "Quickly configure the essentials" method. Although quick configuration does not solve all problems (e.g. OAB download if no OAB has been generated yet), it prevents users from receiving certificate warnings.
A valid certificate is therefore required, which can be prepared. The certificate can then be assigned to the Exchange services directly after installation. The certificate can either be purchased in advance from a CA or a certificate can be issued by an internal PKI.
Here are the corresponding HowTos for the certificates (also applies to Exchange 2016):
In addition, the URLs must be configured accordingly directly after installation; the corresponding commands can also be prepared here:
$servername = "EX2016" $internalhostname = "outlook.frankysweb.de" $externalhostname = "outlook.frankysweb.de" $autodiscoverhostname = "autodiscover.frankysweb.de" $owainturl = "https://" + "$internalhostname" + "/owa" $owaexturl = "https://" + "$externalhostname" + "/owa" $ecpinturl = "https://" + "$internalhostname" + "/ecp" $ecpexturl = "https://" + "$externalhostname" + "/ecp" $ewsinturl = "https://" + "$internalhostname" + "/EWS/Exchange.asmx" $ewsexturl = "https://" + "$externalhostname" + "/EWS/Exchange.asmx" $easinturl = "https://" + "$internalhostname" + "/Microsoft-Server-ActiveSync" $easexturl = "https://" + "$externalhostname" + "/Microsoft-Server-ActiveSync" $oabinturl = "https://" + "$internalhostname" + "/OAB" $oabexturl = "https://" + "$externalhostname" + "/OAB" $mapiinturl = "https://" + "$internalhostname" + "/mapi" $mapiexturl = "https://" + "$externalhostname" + "/mapi" $aduri = "https://" + "$autodiscoverhostname" + "/Autodiscover/Autodiscover.xml" Get-OwaVirtualDirectory -Server $servername | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl Get-EcpVirtualDirectory -server $servername | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl Get-WebServicesVirtualDirectory -server $servername | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl Get-ActiveSyncVirtualDirectory -Server $servername | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl Get-OabVirtualDirectory -Server $servername | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl Get-MapiVirtualDirectory -Server $servername | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl Get-OutlookAnywhere -Server $servername | Set-OutlookAnywhere -externalhostname $externalhostname -internalhostname $internalhostname -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate' Get-ClientAccessService $servername | Set-ClientAccessService -AutoDiscoverServiceInternalUri $aduri
The configuration can now be completed as usual. Which path is chosen therefore depends on the environment.