Planning and migrating a small organization from Exchange 2007 to 2013 (Part 12)

By /

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

Introduction

In the last part of this series we made post-install changes to Exchange 2013, and then generated and applied new SSL certificates to ensure we can co-exist happily with Exchange 2007; along with exporting the new SSL certificate as a PFX file ready to import into our legacy Exchange server and TMG server.

Let’s begin…

New SAN/UCC SSL Certificate Generation Continued

Importing the certificate to TMG and Exchange 2007 Servers

Getting the certificate imported to each server and then enabling the certificate are two separate processes. So by importing the certificate now we’re looking to achieve a simple goal: ensure that when we need to enable the certificate on TMG and Exchange 2007, the certificate is already installed and available.

The process to import the certificate into TMG differs slightly from Exchange 2007, as there is no built-in import and validation process for TMG. Therefore to import the certificate onto our TMG server, we’ll open up the Microsoft Management Console using the command mmc.exe.

After opening the MMC, choose File>Add Remove Snap-ins and select Certificates from the list of available snap-ins. When prompted choose the Local Computer to enable us to manage the TMG server’s available certificates:

Image
Figure 1: Adding the Certificates Snap-in to the MMC

After adding the Local Computer Certificates Snap-In, navigate to Certificates>Personal>Certificates. You should see the existing SSL certificate TMG is already listed within the Certificate Store. If that’s the case, then we are in the right location and can go ahead and choose All Tasks>Import… from the menu:

Image
Figure 2: Importing the PFX file into the Local Computer’s Personal Cert Store

The Certificate Import Wizard should now display, offering the opportunity to enter the file name of the PFX file we exported in the previous section. If you’ve got direct access from the TMG server to the location you exported the PFX file to you can enter the network path here, or if you copied the PFX file to the server, browse for it’s location:

Image
Figure 3: Specifying a network location to import the PFX file from

After entering the password to the PFX file, the certificate should show in the list of certificates alongside the currently enabled certificate.

Next, we’ll need to perform the same operation (but in a slightly different way) on the Exchange 2007 server. Using the Exchange 2007 Management Shell, we will use the Import-ExchangeCertificate cmdlet to import the PFX file and specify the password:

Import-ExchangeCertificate -Path \\E15M01\C$\Certs\Coexistence.pfx -Password (Get-Credential).Password

The command above specifies the network location that the currently logged on user can access, and will also issue a password prompt to allow us the opportunity to enter the PFX file password.

After importing the certificate we should see the certificate Thumbprint, the Services which it is enabled for (none) and the Subject in the Exchange Management Shell:

Image
Figure 4: Importing the PFX file onto Exchange 2007 and recording the Cert Thumbprint

Make a note of the Thumbprint value (as highlighted above), as we’ll require this later on when we enable the SSL certificate for use at the point of enabling coexistence.

Configuring Exchange URLs

With our certificates in place and ready to go on all relevant servers, and enabled on Exchange Server 2013 it is now time to configure the HTTPS URLs for each of the services Exchange provides.

We’ve already set the Service Connection Point to the Autodiscover name, so we will not need to do this elsewhere. Although the Autodiscover Virtual Directory is listed and can be populated with URLs, there is no need to do so and no purpose is served by the configuration.

However we will need to configure additionally services, including:

  • Outlook Web App
  • The Exchange Admin Center (aka ECP)
  • Exchange ActiveSync
  • Exchange Web Services
  • The Offline Address Book
  • and Outlook Anywhere

As we are using a single HTTPS name, mail.exchangelabs.co.uk this is a straightforward process. Let’s examine how to adjust the Exchange URLs both via the Exchange Admin Center and via the Exchange Management Shell.

Using the Exchange Admin Center

If you prefer to use a GUI to make changes to Exchange, the positive news with Exchange 2013 is that you can now adjust the URLs for all virtual directories through the Exchange Admin Center. In Exchange 2007 and Exchange 2010, one important virtual directory – Exchange Web Services – had to be configured via the Exchange Management Shell.

To change the Virtual Directories URLs used for Exchange 2013, we’ll open the Exchange Admin Center and navigate to Servers>Virtual Directories.

We’ll first save ourselves a little bit of work by selecting Configure External Access Domain represented by a spanner:

Image
Figure 5: Navigating to the Virtual Directory section of the EAC and configuring the External Access Domain

This single-step wizard will allow us to configure the External URL for all relevant virtual directories on our Exchange 2013 servers using our common HTTPS name. Simply select the Exchange 2013 server, and enter the HTTPS name, in our case mail.exchangelabs.co.uk:

Image
Figure 6: Selecting the Exchange 2013 server to apply the HTTP name to

After pressing Save, behind the scenes the Exchange Admin Center will execute PowerShell to update each Virtual Directory, so this may take a few moments to complete.

Although this step saved us some time, it didn’t do all the work for us. We’ll now need to edit each Virtual Directory for our OWA, ECP, ActiveSync, EWS and OAB virtual directories to update the Internal URL to match. That’s every virtual directory apart from Autodiscover and Powershell which should be left as-is.

To make these changes select each virtual directory one by one and choose Edit, as shown below.

Image
Figure 7: Selecting individual Virtual Directories

Then, for each virtual directory copy the External URL value into the Internal URL field, then press Save:

Image
Figure 8: Updating the Internal URL to match the External URL already configured

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 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 E15M01 and HTTPS name mail.exchangelabs.co.uk and then updated each Virtual Directory accordingly, saving us time and hopefully ensuring accuracy:

Image
Figure 9: Updating Virtual Directories using the EMS

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 2007 server.

To update these values, navigate to Servers and then choose Properties for the Exchange 2013 server, then choose Outlook Anywhere. Update the External Host Name, Internal Host Name and Authentication Method as shown below:

Image
Figure 10: Updating Outlook Anywhere HTTPS names and authentication method

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 they are re-loaded into IIS, we’ve in theory got our server ready to test mailboxes with. However before we get ahead of ourselves, we’ll make sure we’ve got some additional configuration in place first.

Configuring Transport

It would be a strong statement to suggest it’s vital to configure transport in Exchange 2013 – the defaults are a vast improvement over previous versions – however it’s pretty important to make sure the configuration your require is in place before you begin testing your new Exchange Server.

Two vital components of mail flow within Exchange are Send Connectors and Receive Connectors. The first, Send Connectors, are stored within Active Directory and retain configuration settings across servers; therefore when we move Send Connectors across to Exchange Server 2013 our main focus for changes is against servers that Exchange sends to, such as mail relays.

The latter, Receive Connectors are defined on a per-server basis and as such require re-configuration on Exchange Server 2013.

Configuring Receive Connectors

Before we make any changes to receive connectors on our Exchange 2013 server, we’ll re-visit the information we recorded from our Exchange 2007 server earlier in the series.

If you’re familiar with Exchange you’ll see that the configuration on our Exchange 2007 server is fairly straightforward. We have the two default connectors Client E12M01 and Default E12M01 both with a small amount of changes.

We also have present an additional receive connector, named Anonymous Relay E12M01, which allows clients from a small IP address range to submit mail without authentication intended for both internal and external recipients.

Server Receive   Connector Max   Message Size (KB) IP/Port Accept   Mail From Authentication Permission   Groups Anonymous   Relay
E12M01 Anonymous Relay E12M01 10240 All/25 192.168.15.210-192.168.15.220 – TLS

– Externally Secured

 – Anonymous users Yes
E12M01 Client E12M01 10240 All/587 All – TLS

– Basic (after starting TLS)

– Integrated Windows Auth

 – Exchange users No
E12M01 Default E12M01 1024 All/25 All – TLS

– Basic (after starting TLS)

– Exchange Server Auth

– Integrated

Windows Auth

 – Exchange users

– Exchange servers

– Legacy Exchange servers

– Anonymous users

 No

Table 1

We’ll get started with our changes by first opening the Exchange Admin Center, and navigating to Mail Flow>Receive Connectors:

Image
Figure 11: Navigating to the new Mail Flow section to edit Receive Connectors

While you’re in the Mail Flow section of the EAC you’ll also become aware of some great changes – all mail flow related configuration is now held within one place – so you no longer have to navigate to multiple sections to reconfigure Send and Receive Connectors.

You’ll also notice another change when you view the list of Receive Connectors. In Exchange Server 2013, receive connectors are now split into Front End Transport and Hub Transport types of connectors – each owned by the Client Access and Mailbox roles respectively. As such we’ll need to accommodate these changes when making configuration changes – we won’t simply remove the existing connectors and start again.

For each of the Default and Client Receive Connectors, we’ll examine their configuration, paying special attention to Maximum Receive sizes. These in particular are where we may need to increase or decrease size limits to ensure our configuration remains consistent.

For our Anonymous Relay connector, we’ll begin by pressing the Add button to begin the New Receive Connector wizard.

Because your configuration is likely to vary ensure that as you proceed through this wizard you enter relevant settings for your organization, so use this example to help familiarize yourself with how we apply the settings for Exchange Labs’ Anonymous relay connector.

On the first page of the wizard, enter the name for the receive connector, then choose Frontend Transport to define that it’s a connector that clients will connect to; then select a type of Custom:

Image
Figure 12: Entering basic settings for a new Anonymous Relay connector

On the next page, we’ll be provided with the opportunity to specify Network Adapter Bindings – the IP address and TCP/IP port that the receive connector will listen on. Our example receive connector will listen on the standard port for SMTP, port 25:

Image
Figure 13: Selecting IP bindings and port configuration for the new connector

On the final page of the wizard, we’ll choose which IP addresses the receive connector will accept mail for. This allows multiple receive connectors to listen on the same TCP/IP port and IP address and swing into action depending on the remote IP address of a client. As our anonymous receive connector only allowed mail relay from the IP addresses 192.168.15.210-220, we’ll specify that range here:

Image
Figure 14: Selecting the scope of the new connector

After completing the wizard, we’ll then open the properties of our new receive connector and update additional settings to match our Exchange 2007 Server. First, we’ll update the Maximum receive message size to 10MB on the General tab:

Image
Figure 15: Adjusting message size limits for the new receive connector

And finally, we’ll select the Security tab and update the settings for Authentication and Permission Groups to match our table above:

Image
Figure 16: Adjusting security settings to match Exchange 2007

With these settings in place, our new Exchange 2013 server should be ready to accept mail using the same set of parameters the Exchange 2007 server used.

Summary

With HTTPS URLs, Outlook Anywhere and Transport configured for Exchange, a number of key components required before Exchange 2013 can coexist are now in place.

In the next part of this series, we’ll get our Exchange Server ready for Mailbox Moves by configuring Mailbox Databases before moving onto testing everything works as expected.

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

About The Author

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

Read Next

1 thought on “Planning and migrating a small organization from Exchange 2007 to 2013 (Part 12)”

  1. Rob

    Hi Paul,
    In section 12 regarding Outlook Anywhere you’ve missed setting about “Allow SSL offloading” check box. If you’re not using any load balaner should this box should be unchecked either way OA will not work ?

    Thanks
    Rob

    Reply

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