Migrating a small organization from Exchange 2010 to Exchange 2016 Part 3

In the first two parts of this series we performed the basic design and implementation of Exchange Server 2016 into our organization. In this part of the series, we’ll perform the first post-configuration steps.

Post-Installation Configuration Changes

Checking Exchange After Installation

After installation completes we will ensure that the new Exchange Server is available.

Choose Start and launch the Exchange Administrative Center from the menu, or navigate using Internet Explorer to https://servername/ecp/?ClientVersion=15:


Figure 1: Launching the EAC

When launching via a localhost URL and because we haven’t installed the real SSL certificate we will see a certificate warning, as shown below. Click Continue to this website to access the EAC login form:


Figure 2: First login to the EAC

You should see the Exchange Admin Center login form. Login using an organization admin credentials:


Figure 3: Login as an Admin to the EAC

After you successfully login, take a moment to navigate around each section of the EAC to familiarise yourself with the new interface.


Figure 4: Exploring the Exchange 2016 EAC

You’ll notice that the EAC is very different in layout to Exchange Server 2010’s Exchange Management Console. In Exchange 2010 and 2007, the focus was based on the organization, servers and recipients with distinct sections for each. Exchange 2013 and 2016 move to a more task-oriented view. For example, Send and Receive connectors are both managed from the Mail Flow section rather than hidden within respective Organization and Server sections.

However even with those changes, very similar commands are used within the Exchange Management Shell and you will be able to re-purpose any Exchange 2010 PowerShell skills learnt.

Updating the Service Connection Point for Autodiscover

After successfully installing Exchange Server 2016, a change worth making is to update the Service Connection Point (SCP).

The SCP is registered in Active Directory and used, alongside the Exchange 2010 SCP as a location Domain-Joined clients can utilize to find their mailbox on the Exchange Server.

By default, the SCP will be in the form https://ServerFQDN /Autodiscover/Autodiscover.xml; for example https://EX1601.goodmanindustries.com/Autodiscover/Autodiscover.xml.

The name above however won’t be suitable for two reasons – firstly, no trusted SSL certificate is currently installed on the new Exchange 2016 server, and the SSL certificate we’ll replace it with in the next section won’t have the actual full name of the server.

This can cause certificate errors on domain-joined clients, most commonly with Outlook showing the end user a certificate warning shortly after you install a new Exchange Server.

Therefore, we will update the Service Connection Point to use the same name as the Exchange 2010 uses for its Service Connection Point. This is also the same name we’ll move across to Exchange 2016 later on.

To accomplish this, launch the Exchange Management Shell from the Start Menu on the Exchange 2016 server:


Figure 5: Launch the EMS

To update the Service Connection Point, we’ll use the Set-ClientAccessService cmdlet from the Exchange Server 2016 Management Shell, using the AutodiscoverServiceInternalURI parameter to update the actual SCP within Active Directory:

Set-ClientAccessService -Identity EX1601 -AutodiscoverServiceInternalURI https://autodiscover.goodmanindustries.com/Autodiscover/Autodiscover.xml


Figure 6: Updating the SCP

After making this change, any clients attempting to use the Exchange 2016 Service Connection Point before we implement co-existence will be directed to use Exchange 2010.

Exporting the certificate as PFX format from Exchange 2010

Because we will migrate the HTTPS name from Exchange 2010 to Exchange 2016 we can re-use the same SSL certificate by exporting it from the existing Exchange server.

To perform this step, log in to the Exchange 2010 server and launch the Exchange Admin Console. Navigate to Server Configuration in the Exchange Management Console, select the valid SSL certificate with the correct name, then select Export Exchange Certificate from the Actions pane on the right hand side.


Figure 7: Exporting the Exchange 2010 SSL cert

The Export Exchange Certificate wizard should open. Select a location to save the Personal Information Exchange (PFX) file and an appropriate strong password, then choose Export:


Figure 8: Specifying an export directory and password

Make a note of this location, as we’ll use it in the next step.

Importing the Certificate PFX File

Back over on the Exchange 2016 server, open the Exchange Admin Center and navigate to Servers>Certificates. Within the more (…) menu choose Import Exchange Certificate:


Figure 9: Importing the SSL certificate to Exchange 2016

In the Import Exchange Certificate wizard we’ll now need to enter a full UNC path to the location of the exported PFX file, along with the correct password used when exporting the certificate from Exchange 2010:


Figure 10: Specifying the path to the Exchange 2010 server

After entering the location and password, we’ll then choose Add (+) to select our Exchange 2016 server, EX1601, as the server to apply this certificate to. We’ll then choose Finish to import the certificate:


Figure 11: Selecting appropriate servers to import the certificate to

Assigning the SSL certificate to services

Although we now have the SAN SSL certificate installed on the Exchange 2016 server it is not automatically used by services such as IIS, SMTP, POP/IMAP or Unified Messaging. We’ll need to specify which services we want to allow it to be used with.

To perform this step, within Certificates select the certificate and then choose Edit:


Figure 12: Assigning SSL certificates for use

Next, choose the Services tab in the Exchange Certificate window and select the same services chosen for Exchange 2010. In this example, we’re only enabling the SSL certificate for IIS (Internet Information Services):


Figure 13: Selecting services to assign the SSL cert to

After the certificate is assigned, ensure it is in applied to IIS by running the following command:

iisreset /noforce

Configuring Exchange URLs using the Exchange Management Shell

The Exchange Management Shell also provides the functionality to change the Exchange URLs for each virtual directory, however unless you know the syntax it can be a little intimidating – and even if you do know the relevant syntax, typing each URL can be a little time consuming too.

We can use a PowerShell script to make this process simpler.

The first two lines of the script are used to specify the name of the Exchange 2016 server, in the $Server variable, and the HTTPS name used across all services in the $HTTPS_FQDN variable.

The subsequent lines use this information to correctly set the Internal and External URLs for each virtual directory:

$Server = “ServerName”

$HTTPS_FQDN = “mail.domain.com”

Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/owa” -ExternalURL “https://$($HTTPS_FQDN)/owa”

Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/ecp” -ExternalURL “https://$($HTTPS_FQDN)/ecp”

Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/oab” -ExternalURL “https://$($HTTPS_FQDN)/oab”

Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync” -ExternalURL “https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync”

Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/EWS/Exchange.asmx” -ExternalURL “https://$($HTTPS_FQDN)/EWS/Exchange.asmx”

Get-MapiVirtualDirectory -Server $Server | Set-MapiVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/mapi” -ExternalURL “https://$($HTTPS_FQDN)/mapi”

In the example below, we’ve specified both our server name EX1601 and HTTPS name mail.goodmanindustries.com and then updated each Virtual Directory accordingly:


Figure 14: Updating URL values

Configuring Outlook Anywhere

After updating the Virtual Directories for Exchange, we’ll also update the HTTPS name and authentication method specified for Outlook Anywhere.

As Outlook Anywhere is the protocol Outlook clients will use by default to communicate with Exchange Server 2016, replacing MAPI/RPC within the LAN, it’s important that these settings are correct – even if you are not publishing Outlook Anywhere externally.

During co-existence it’s also important to ensure that the default Authentication Method, Negotiate, is updated to NTLM to ensure client compatibility when Exchange 2016 proxies Outlook Anywhere connections to the Exchange 2010 server.

To update these values, navigate to Servers and then choose Edit against the Exchange 2016 server:


Figure 15: Locating Outlook Anywhere settings

In the Exchange Server properties window choose the Outlook Anywhere tab. Update the External Host Name, Internal Host Name and Authentication Method as shown below:


Figure 16: Updating Outlook Anywhere configuration

Naturally you can also accomplish this with PowerShell, however it’s just as quick to use the Exchange Admin Center for a single server.

With these settings configured, along with iisreset /noforce to ensure configured is re-loaded into IIS we could in theory move client access across from Exchange 2010 to Exchange 2016. Before we do that we will first make some additional configuration changes.


In part three of this series, we’ve performed the first basic configuration required for our Exchange 2016 server post-installation. In part four we will complete the post-installation configuration and begin preparation for migration.