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

By /

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

Introduction

In this multi-part article series, we’re looking at how to migrate from Exchange 2007 to Exchange 2013 in the context of a smaller organization. This series will aim to help you understand the deployment challenges associated with migrating to Exchange 2013 on a wider scale. Now let’s focus on the pre-requisite discovery, remediation, planning and sizing before moving on to the larger task of deploying Exchange 2013, configuring co-existence, migrating mailboxes and public folders along with decommissioning Exchange 2007.

The first part of this series begins by looking at our current infrastructure and walking through the steps we’ll take to migrate to Exchange 2013.

Our Example Organization

As the series title suggests, we’ll looking to migrate a smaller organization to Exchange 2013. Our example organization is Exchange Labs, a fictional scientific laboratory that specialise in the testing of items replaced by retailers. With around 500 staff, Exchange Labs have been making do with the now positively ancient Exchange 2007 for a few years and didn’t upgrade to Exchange 2010 as they didn’t feel it offered enough to justify the expense of moving.

With a gradual move to a “bring your own device” culture, demand for larger mailboxes and future projects to implement eDiscovery, Lync and SharePoint across the organization, Exchange Labs now feel it makes sense to move to Exchange 2013. There’s also a real possibility they may expand significantly in the future, and while a multi-site highly available deployment isn’t needed now, they need the right platform to support easy expansion later on.

Of course, being a fictional organization – none of that’s actually true. The reason we’re using the above example for this series is primarily so we can help you understand the important aspects of migrating to Exchange 2013 for Exchange 2007 organizations, rather than detract with topics like high availability that are best covered separately.

Current Exchange 2007 Organization

With the above in mind, we’ll take a look at the current Exchange Labs organization. To give this a dose of reality, we’ve got some common add-ons that you’ll find in a smaller organization today, alongside Exchange itself:

Image
Figure 1: Diagram of Exchange, AD, MailEssentials, TMG, BES

If you’ve studied the diagram you’ll see we’ve got a single Exchange Server. This hosts a number of Mailbox Databases along with Public Folders providing users with 500MB quotas.

In addition to the Exchange Server, we’re using some other solutions to provide security and additional device access.

Microsoft Forefront Threat Management Gateway (TMG) 2010 is installed with an arm inside Exchange Lab’s perimeter network and is used to provide access to Exchange both for internet users and non-domain joined devices such as tablets connected to the on-premises Wireless LAN.

Exchange Labs currently have opted for an on-premises message scanning solution, in this case MailEssentials, however the exact product is not important. This lives within the perimeter network and is responsible for scanning inbound and outbound messages for spam and malware.

Exchange Labs also have a number of Blackberry device users that require the use of Blackberry Enterprise Server (BES).

Outside of the diagram, we’ve got an underlying backup and restore solution. Naturally backups, whether Exchange Native Protection or traditional, are a critical piece of your Exchange infrastructure. Like High Availability we will cover the importance during this series, but won’t cover the implementation simply because the solutions in use vary widely and many are still being updated for Exchange 2013 support.

During Coexistence

Coexistence is the phase of the migration where we’ve implemented Exchange 2013 but are still in the process of migrating users. This means that we’ll want the front-end services client’s access to be Exchange 2013 first, but provide seamless access to the existing Exchange 2007 environment. This results in both solutions running side-by-side, as shown below:

Image
Figure 2: Diagram of Exchange 2007, AD, MailEssentials, TMG, BES, with Exchange 2013 and Office Web Apps Server

What you’ll see above is that we’ll continue to make use of TMG – in fact, as we go into more detail later, TMG will provide a workaround for one of the major challenges with coexistence and forms-based authentication with Exchange 2007 and 2013. Under the hood, we’ll also have updated third-party software like our BES server to ensure they can talk to Exchange 2013 correctly.

Target Exchange 2013 Organization

After we’ve moved all the mailboxes over, migrated our Public Folder infrastructure over, updated various bits and pieces we’ll get naturally decommission Exchange 2007. Our final diagram shows what the relevant Exchange related organization will look like:

Image
Figure 3: Diagram of final Exchange 2013 state

From that point on – the sky is the limit. Exchange Labs might choose in a few years to migrate to Exchange Online, or they might choose to add in additional servers and a load balancer to provide HA – all with minimal (or potentially no) user disruption.

Key Migration Tasks

Before we get our hands dirty, we’ll stand back and take a high level look at the tasks we’ll need to accomplish. This set of tasks might be something you’d find in a High Level Design or similar document with resource requirements alongside. For this series though, it’s to help you understand as we go through each part of the series exactly how far along we are and what we’ll still have left to do.

  • Discovery – We’ll look at what tools you need to use, including my Exchange Environment Report to get a real feel for the organization we’re taking on; the Exchange Profile Analyser to get some meaty detail about the existing user profiles, look for any underlying issues we need to resolve, and gather information about quotas, size limits, transport, client access configuration along with client information and third-party appliance information.
  • Planning for Deployment – Although our actual final solution won’t involve deploying a Database Availability Group, we’ll talk though HA requirements you might need to consider, get an understanding for the new patching model for Exchange and look at backup and restore options. We’ll then start to get some facts and figures down on paper to define internal naming, quota requirements, what we’ll look to do with Mailbox Databases and Public Folders and then conduct sizing our Exchange 2013 environment. We’ll also plan for additions including Office Web Apps Server, underlying Operating System choices and discuss and plan our coexistence scenario.
  • Pre Deployment Remediation – Before we throw Exchange 2013 in, we’ll start with ensuring that the current environment is up to scratch, and cover the areas we’ll need to remediate based on both the discovery findings and in general to avoid any Exchange 2013 gotchas.
  • Installing base hardware, configuring storage and Exchange pre-requisites – Getting the base platform right is critical to any Exchange implementation, so we’ll make sure the storage matches the design.
  • Storage Subsystem testing – Using Microsoft’s recommended tool, JetStress 2013 we will test the underlying storage infrastructure and analyse the results to ensure that they meet the requirements our discovery and planning dictated.
  • Installing Exchange 2013 Schema Updates and Multi-Role Servers – After many preparation stages we’ll install Exchange 2013 itself into the Exchange 2007 organization.
  • Post-installation configuration – As you might imagine, after the installation of Exchange 2013 we have a few things to do both immediately so it doesn’t affect end users, and then a few more tasks to get it ready for co-existence. These include configuring new certificates, updating settings for Exchange URLs to match those defined earlier, configuring transport settings and of course configuring Mailbox Databases to design. We’ll also begin testing to make sure we’re ready to configure the next big step…
  • Configuring Coexistence – The set of tasks associated with coexistence are where it gets even more interesting. After configuring coexistence, end-users will begin to access Exchange 2013 on a daily bases for AutoDiscover, and services Exchange 2013 proxies or redirects like Outlook Web App and Exchange ActiveSync. So it’s critical we get it right or we’ll have caused users issues before we’ve even began the migration. We’ll look to move our TMG and Exchange 2007 servers to use our new set of SSL certificates, create new DNS records to support coexistence, update URLs within Exchange 2007. We’ll add new rules into TMG and update existing ones, along with reconfigure mail routing.
  • Preparing for Migration – After successfully configuring coexistence we’ll now be ready to perform the real-world testing that will validate our Exchange 2013 configuration. We’ll look to perform base functionality tests alongside a list of client tests for internal, external and third-party clients that we found out during Discovery. We’ll implement backup software (or talk about it, for the purposes of this series) and decide upon the correct migration strategy for end-users. The latter tasks for preparing the migration include some pre-pilot migrations, reviewing any issues, preparing end-user communications and considerations for Exchange management.
  • Migrating Mailboxes – With our planning, configuration and testing complete, we open the doors to Exchange 2013. For our 500-user organization, we’ll begin with a pilot set of users from across the organization to further validate the process, review any feedback and then migrate the remaining mailboxes. Because we’ve put the effort into earlier tasks, the migration should present few issues.
  • Updating and Migrating what’s left – As with previous migrations between Exchange versions, we’ll need to upgrade the version stamped on AD objects like Distribution Groups. A slightly different task however is the migration of Public Folders. With users across to Exchange 2013 we’ll look to migrate the organization over to Modern Public Folders in a safe, reasonably simple way.
  • Decommissioning Exchange 2007 – Before we rip out Exchange 2007, we’ll validate that all services have been moved across; for example ensuring the odd Application Server or Multi-Function Copier doesn’t continue to relay mail though Exchange 2007. We’ll then remove the configuration used for coexistence and then, step by step, remove Exchange 2007 safely.

Summary

In part one of this series, we’ve looked at the high level overview describing what we’ll look to achieve during our migration to Exchange 2013, and collected information about the organization that will assist us with our next steps. In part two of this series, we’ll perform the bulk our first major task – Discovery.

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

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

  1. Bill Kennedy

    I know this is an old post from 5 years ago, but followed it to the letter, and it worked like a champ for my Production Server! Thank you

    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