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

By /

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

Getting the clients ready for the upgrade

Updating Outlook 2010 and 2007 Clients

In part three of this series we looked at the methods available to identify existing clients, and if you haven’t updated clients now is the time to do so. Autodiscover responses from Exchange 2013 contain new methods to support internal Outlook Anywhere, and these updates ensure support for this in addition to other fixes.

To recap, the update levels we’ll need to achieve are as follows:

  • Outlook 2010 Service Pack 1 with at least the November 2012 update (Build 14.0.6126.5000 or higher)
  • Outlook 2007 Service Pack 3 with at least the November 2012 update (Build 12.0.6665.5000 or higher)

Naturally if you can update clients to Outlook 2013 that’s even better as your users will be able to benefit from new features, such as Apps for OWA and Outlook 2013; however as we mentioned in part three you need to be aware that Outlook 2013 cannot connect to Exchange Server 2003, leaving us the following options:

  • Only upgrade Outlook 2003 or earlier clients to Outlook 2010 rather than Outlook 2013.
  • Leave some mailboxes on Exchange 2010 for a longer period once they can be upgraded to the latest versions, prolonging the migration process.
  • Force unsupported clients to use Outlook Web App instead of Outlook/Entourage after migration, until their client is updated.

For Outlook 2007 and 2010 clients use tools like Windows Server Update Services (as mentioned in part four of this series) to ensure clients meet minimum update levels or higher. With the recent release of Outlook 2010 Service Pack 2, there’s even more reason to get clients updated.

Removing unsupported clients

If your client discovery identified any clients that aren’t supported with Exchange 2013, then you’ll need to start replacing these now. Remember – Outlook 2003 and below aren’t supported so if you’re using this within your organization, upgrade these clients to at least the above versions of Outlook before we start the upgrade.

Converting Exchange Server 2003

Switching to Native Mode

Before we prepare Active Directory for Exchange Server 2010, we’ll make our first change to the existing Exchange infrastructure by ensuring that Exchange Server 2003 is configured in Native Mode. To configure this, right-click the organization name in Exchange System Manager and choose Properties:

Image
Figure 1: Opening the organization properties in Exchange 2003

The organization and MMC properties will display. We’ll then check for the Operation Mode setting. If it’s set to Mixed Mode, then choose Change Mode:

Image
Figure 2: Viewing and changing the operation mode

We’ll then – assuming you don’t have any Exchange 5.5 servers left – choose Yes to switch from Mixed Mode to Native Mode:

Image
Figure 3: Warning to show that the mode cannot be reversed

After making the change, you’ll see the operation mode updates to Native Mode:

Image
Figure 4: Organization mode showing Native Mode

Switching Windows Integrated Authentication on for ActiveSync on Back-End Servers

We’ll also need to make a change to Exchange 2003 to support ActiveSync coexistence. This patch allows the Exchange 2010 server to use Windows Integrated Authentication when it proxies authenticated requests back to the Exchange 2003 server.

To enable this change we’ll need to first install KB937031 from the Microsoft Support website. This patch is required because by default the option for Windows Integrated Authentication isn’t available in the Exchange System Manager, and if we change it manually in Internet Information Services Manager, Exchange will change it back.

To make the change we’ll need to install the patch on at least one Exchange 2003 server, then make the configuration change against the Back-End Exchange 2003 server, which in our organization is LJD-E2003BE.

Before installing the patch, close all instances of the Exchange System Manager on the server, then install the patch. Assuming the Exchange System Manager was indeed closed, the patch installer will complete without requiring a reboot:

Image
Figure 5: Installing KB937031

After installing the hotfix, launch the Exchange System Manager. Expand the Administrative Group, then Servers, then for each back-end server expand Protocols, then HTTP, then Exchange Virtual Server and right-click and choose Microsoft-Server-ActiveSync, then choose Properties:

Image
Figure 6: Selecting the ActiveSync virtual directory in the Exchange System Manager

In the ActiveSync properties window, choose Access, then choose Authentication:

Image
Figure 7: Selecting the authentication methods in the Access tab

Within Authentication Methods, we’ll then choose Integrated Windows Authentication, then press OK:

Image
Figure 8: Changing the authentication methods to include Integrated Windows Authentication

For our smaller organization we don’t need to make additional changes to the organization, though if you do have a larger organization with multiple routing groups, consider suppressing Link State Updates, by following the instructions in this Technet article.

Installing the Exchange 2010 Multi-Role Server

With Exchange Server 2003 ready to go, we’ll get on with the installation of our fully tested Exchange 2010 multi-role server on Windows Server 2012.

As we’ve pre-installed all pre-requisites for Exchange 2010 we’ll use the command prompt to perform a rapid installation. Launch a command prompt as an administrator and then change directory into the folder that the Exchange Server 2010 Service Pack 3 setup files were extracted into – in our case C:\Exchange2010SP3.

Exchange 2010 Schema Preparation

We’ll then perform the Active Directory Schema Preperation. This is an irreversible step, so ensure you perform a full backup of your Active Directory first, then run the following command:

setup.com /PrepareSchema

Image
Figure 9: Installing the Exchange 2010 Schema

Exchange 2010 Active Directory Preparation

After the schema preparation completes successfully we are ready to move onto the second step, the Active Directory preparation. This is where the Configuration Container, where Exchange “lives” is prepared for the Exchange 2010 installation. To perform this step run the following command:

setup.com   /PrepareAD

Image
Figure 10: Preparing the Active Directory for Exchange 2010

Exchange 2010 Roles Installation

Our final Active Directory related step is to prepare the Active Directory domains in the forest. For a single domain and to prepare all domains, if you happen to have multiple domains, run the following command to update and create relevant Active Directory security groups and user accounts:

setup.com   /PrepareAllDomains

Image
Figure 11: Preparing the AD Domains for Exchange 2010

With Active Directory ready, we are now able to install Exchange Server 2010. As our staging server is a multi-role server we will install the Client Access (CA), Hub Transport (HT) and Mailbox (MB) roles. We’ll use the following command to accomplish this:

setup.com /mode:install   /roles:CA,HT,MB

Image
Figure 12: Installing the multi-role Exchange 2010 staging server

This final step will take some time, as it’s going to install all the typical multi-role components of Exchange Server 2010 and the subsequent update rollup that we have pre-installed earlier within the Updates folder in the installation folder. After a successful installation expect to see each role, followed by Finalizing Setup showing as Completed:

Image
Figure 13: Verification that Exchange 2010 installed correctly

Creating and applying our Exchange 2010 and 2013 SSL certificate

Generating the new certificate signing request

Now Exchange Server 2010 is installed we are ready to generate the Certificate Signing Request (CSR) for our new SSL certificate that will be used both on the Exchange 2010 staging server and the Exchange 2013 server we will install shortly.

As a reminder, we chose the following names for Exchange 2010 and 2013 in part four of this series, so we will use these names when generating the new SSL certificate request:

Exchange 2010 /   2013 Namespaces
mail.lisajanedesigns.co.uk

autodiscover.lisajanedesigns.co.uk

Table 1

We’ll use the Exchange Management Console to create the CSR, as it’s got a great wizard to make this very easy. Launch the Exchange Management Console from the Start Page:

Image
Figure 14: Launching the Exchange Management Console

In the Exchange Management Console, select Server Configuration but do not expand it, then select the Exchange 2010 staging server from the list. It should be the only server listed. Then choose New Exchange Certificate from the Actions panel on the right hand side:

Image
Figure 15: Creating the new Exchange Certificate

The New Exchange Certificate wizard will launch. This is the tool that will create our new CSR. First, choose a “Friendly Name” for the certificate. This will be shown in the Exchange 2010 Management Console and the Exchange 2013 Admin Center, so choose something descriptive:

Image
Figure 16: Choosing a friendly name for the certificate

If you’re not sure what to choose, don’t worry too much as you can change it later, but you’ll have the use the certificate management MMC snap-in.

We’ll skip Enable Wildcard Certificate and on the Exchange Configuration page expand Client Access server and choose Outlook Web App is on the Internet, then enter our primary name, mail.lisajanedesigns.co.uk before pressing Next:

Image
Figure 17: Entering the primary HTTPS namespace

On the Certificate Domains page we will then add and remove the names listed to match our table of Exchange Names. As per our table above we’ll be left with two names – the Autodiscover name and the HTTPS service name:

Image
Figure 18: Correcting the certificate domains list

We’ll then enter organization details and the path to save the Req file to. Feel free to save the .Req file as a .TXT file as that’s all it is – and you’ll most likely need to copy and paste its contents in later.

After the wizard completes open the saved request file. You’ll expect to see a text file similar to the one below, with a Begin New Certificate Request line followed by the Base 64 encoded binary contents:

Image
Figure 19: Viewing the CSR

After saving the certificate request, visit your preferred third party SSL certificate vendor and use the CSR to generate a new request. You’ll see below we’ve used our CSR to auto-fill names in the example below:

Image
Figure 20: Submitting the CSR to a third-party SSL vendor

Applying the certificate to the Exchange 2010 Server

After the SSL certificate is provided by the third-party SSL vendor we’ll need to save the certificate back to the server, where it can be matched up to our private key and certificate request in Exchange Server.

With the certificate on the local file system, launch the Exchange Management Console again and as before, navigate to Server Configuration, then choose the Pending certificate with the friendly name, as shown below, then choose Complete Pending Request from the Actions pane on the right hand side:

Image
Figure 21: Completing the certificate request

In the Complete Pending Request wizard, select the location of the certificate provided by the third-party SSL certificate vendor, then choose Complete:

Image
Figure 22: Viewing the Complete Pending Request wizard

Summary

We’ve successfully installed our Exchange 2010 staging server into the Exchange 2003 organization in this part of the series, then created and completed a new SSL certificate request. In the next part of this series we’ll continue with Exchange 2010 base setup.

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

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