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

If you would like to read the other parts in this article series please go to:

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:

Image
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:

Image
Figure 2: First login to the EAC

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

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

Image
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:

Image
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

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

Image
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:

Image
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:

Image
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:

Image
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:

Image
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:

Image
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):

Image
Figure 13: Selecting services to assign the SSL cert to

After the certificate is assigned, ensure it is 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:

Image
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:

Image
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:

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

Summary

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.

If you would like to read the other parts in this article series please go to:

About The Author

12 thoughts on “Migrating a small organization from Exchange 2010 to Exchange 2016 (Part 3)”

  1. I am using oulook 2016 while trying to configure mailbox during the migration on new exchange 2016 with windows logon credential, outlook searching for mailbox and asking me for credential?
    May i know what authentication need to be checked?
    Thank You

  2. In this example, we’re only enabling the SSL certificate for IIS (Internet Information Services):

    Any reason to not enable the other services at this time? Should they be done at a different stage?

    1. @PaulD – no, Exchange 2016 will proxy the connection back to Exchange 2010 if the mailbox exists on the Exchange 2010 server. In other words, you point everything to Exchange 2016, it directs the client locally to EX2K16 if the mailbox has been migrated, if not it proxies on behalf of the client to EX2K10.

      I have an issue where I get the dreaded “something went wrong” web response after trying to logon to Exchange 2016 OWA. I’ve tried removing 127.0.0.1 bindings from IIS, checked the sharepoint webconfig issue, updated Exchange 2016 to CU11, nothing fixes this error. Anytime IIS is a involved, its guaranteed to be IIS at fault. That product needs a complete rewrite.

      Any other ideas?

      1. Ahhh, just as I post that. Found issue, Windows Authentication was not enabled under Exchange 2010 servers IIS for ECP and OWA webs. Sorted.

  3. Thank you for the guide.

    I hit an issue and note it here in case it may help someone.
    After a successful exchange installation, when I tried to access my ECP I was either redirected to OWA or got a 2010 management panel. It took me some minutes to find that adding “/?ExchClientVer=15.1” to the end of my URL would land me in the 2016 ECP so something like this:-

    https://localhost/ecp/?ExchClientVer=15.1

    Cheers.

  4. There is a mistake with your displayed script. The last line I can see is red and looks to be incomplete. This is how it reads to me:

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

    After inspecting your Exchange Management Shell window, I decided I needed to add to the end of the last line so it looks something like this:

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

    Unfortunately I still have a flashing curser at the end of the line and nothing seems to be happening.

    Can you suggest any change that should fix the issue?

    Up until now, everything has gone exactly as expected.

    Thanks so much for a great write up.

    Cheers,

    Howard

  5. OK. I figured it out… I simply had to hit “Enter”. I was used to all the previous Functions simply running themselves when I pasted the script. For the last line I simply had to press “Enter”. I hope this helps someone else.. Once I hit enter on the last “corrected” function, it processed without issue.

    Cheers,

    Howard

  6. for the variable $HTTPS_FQDN = “mail.domain.com” do I want to use my internal mail.domain.local or my outside mail.differentfromdomain.org.

    Thank you so much,

    ABJ

  7. Steve, thanks so much for this, its spot on. question, you mention:

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

    So, after coexistence is complete and the 2010 servers are removed, I should change all my 2016 servers to “Neogtiate” (kerberos)?

    Also, what does this do to outlook clients? modern of course. just prompt them for credentials? new profile? hopefully just a close of outlook and re-open?

    thanks!

    Josh

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top