Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 15)

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

Last time round we completed the decommission of Exchange 2003 and prepared Active Directory for Exchange 2013 deployment, all whilst our users continue to use Exchange 2010.

Installing Exchange Server 2013

Before we install Exchange 2013 we will quickly review the server configuration determined earlier in the series.

For our example organization we’ve built a single server named LJD-E1501:

Hostname Virtual   CPU RAM OS   Disk Page   file Disk Physical   disks required Database   virtual disks Log   virtual disks Restore   LUN
LJD-E1501 2 x vCPU 24GB 100GB 29GB 8 x 4TB 5 x 1707GB 5 x 27GB 1 x 1246GB

Table 1

When we performed the pre-requisite configuration of the server we extracted the Exchange 2013 setup to C:\Exchange2013 and configured the database mount points as below:

Disk Mount Point
Database 1 C:\ExchangeDatabases\DB01
Database 2 C:\ExchangeDatabases\DB02
Database 3 C:\ExchangeDatabases\DB03
Database 4 C:\ExchangeDatabases\DB04
Database 5 C:\ExchangeDatabases\DB05
Database 1 Log C:\ExchangeDatabases\DB01_Log
Database 2 Log C:\ExchangeDatabases\DB02_Log
Database 3 Log C:\ExchangeDatabases\DB03_Log
Database 4 Log C:\ExchangeDatabases\DB04_Log
Database 5 Log C:\ExchangeDatabases\DB05_Log
Restore LUN C:\ExchangeDatabases\Restore

Table 2

Performing Exchange 2013 Setup

We will install Exchange Server 2013 using a similar procedure to the Exchange 2010 server, via the command line. It’s also possible to perform the setup using the GUI, however this method provides great feedback into what is happening under the hood.

This time, we’ll use the /Mode switch to specify that we will be performing an Install. In addition to the /Mode switch we need to specify the roles that we’ll install. As this is a Multi-Role server we will be installing the Client Access and Mailbox roles.

setup.exe   /Mode:Install /Roles:ClientAccess,Mailbox /IAcceptExchangeServerLicenseTerms

Image
Figure 1: Installing Exchange 2013 using unattended setup

As part of the installation via the command line, we’ve got a number of other options available – however for a basic installation we have used the simplest options.

After installation completes we will ensure that the new Exchange Server is working, choose Start and launch the Exchange Administrative Center from the menu, or navigate using Internet Explorer to https://servername/ecp/?ClientVersion=15:

Image
Figure 2: Launching 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 3: Typical certificate error on first access to the EAC

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

Image
Figure 4: Login to the EAC as an administrator

After login, ensure that you can navigate between each section successfully:

Image
Figure 5: Checking the EAC and getting familiar with the new interface

If this is the first time you’ve seen the Exchange Admin Center, then you will see it is very different to both Exchange 2003 and Exchange 2010.

The focus has moved from the organization and server-centric views of settings to a recipient and task based view; for example if you want to configure Receive or Send connectors you access Mail Flow rather than editing settings at the server or organization level in different parts of the UI.

Under the hood, similar commands are used within the Exchange Management Shell and we will use the EMS where appropriate to make changes.

Post-Installation Configuration Changes

Updating the Service Connection Point for AutoDiscover

After successfully installing Exchange Server 2013, 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://ljd-e1501.lisajanedesigns.co.uk/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 2013 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, which is also the name we’ll move across later on whilst implementing co-existence.

To update the Service Connection Point, we’ll use the Set-ClientAccessServer cmdlet from the Exchange Server 2013 Management Shell, using the AutoDiscoverServiceInternalURI parameter to update the actual SCP within Active Directory.

First, launch the Exchange Management Shell from the Start Menu on the Exchange 2013 server:

Image
Figure 6: Launching the EMS

In part 11 of this series, we set the URL on Exchange 2010 to https://autodiscover.lisajanedesigns.co.uk/Autodiscover/Autodiscover.xml therefore we’ll make the same change using the Exchange Management shell on Exchange 2013:

Set-ClientAccessServer -Identity LJD-E1501 -AutoDiscoverServiceInternalURI   https://autodiscover.lisajanedesigns.co.uk/Autodiscover/Autodiscover.xml

Image
Figure 7: Updating the SCP via PowerShell

After making this change, any clients attempting to use the Exchange 2013 Service Connection Point before we implement co-existence will continue to use the Exchange 2010 Staging Server.

Importing the Certificate PFX File

After we created a new SSL certificate on the Exchange 2010 server, back in part 11 of this series, we exported the certificate to a PFX file. In our example we exported the certificate to C:\Certs\mail_lisajanedesigns_co_uk.pfx on LJD-E1401.

To import this certificate we will start by opening the Exchange Admin Center and navigating to Servers>Certificates, then within the more (…) menu choose Import Exchange Certificate:

Image
Figure 8: Importing the Exchange 2010 SAN certificate

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 9: Specifying a UNC path to the PFX location

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

Image
Figure 10: Specifying the Exchange 2013 server as a target for the PFX import

Assigning the SSL certificate to services

Although we now have the SAN SSL certificate installed on the Exchange 2013 server it’s not automatically used by services. 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 (Pencil icon):

Image
Figure 11: Choosing properties for the SSL certificate

Next, choose the Services tab in the Exchange Certificate window and select the same services chosen for Exchange 2010, typically Internet Information Services (IIS):

Image
Figure 12: Assigning the certificate to be used for IIS

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

The good news is that the script below can help make this much easier. What we’ll do is use the first two lines of the script to specify the name of the Exchange 2013 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”

In the example below, we’ve specified both our server name LJD-E1501 and HTTPS name mail.lisajanedesigns.co.uk and then updated each Virtual Directory accordingly, saving us time and hopefully ensuring accuracy:

Image
Figure 13: Updating Internal and External 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 to communicate with Exchange Server 2013, 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 2013 proxies Outlook Anywhere connections to the Exchange 2010 server.

To update these values, navigate to Servers and then choose Edit (Pencil icon) against the Exchange 2013 server:

Image
Figure 14: Editing the server properties

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 15: Updating settings for Outlook Anywhere

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 the obligatory iisreset /noforce to ensure configured is re-loaded into IIS we could in theory move client access across from Exchange 2010 to Exchange 2013. Before we do that we will first make some additional configuration changes.

Summary

Exchange 2013 is now installed into our organization and has basic SSL and URL settings configured. In the next part in this series we will create additional receive connectors to match Exchange 2010, reconfigure the default Mailbox databases and create new mailbox databases to ensure the server meets our design.

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

About The Author

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