Moving from Exchange 2003 to Exchange 2010 in 12 steps

You’ve done your homework on moving from Exchange 2003 to Exchange 2010. Now it’s time to get to work. Here are the 12 main steps you need to take to get the job done.

This article can also be found in the Premium Editorial Download: Exchange Insider: Exchange Server: To host or not to host:

So you’ve decided that Exchange Server 2010 is the way to go? After you’ve done all your homework and reviewed...

the prerequisites of moving completely off of Exchange 2003 and onto Exchange 2010, this tutorial will guide you through the migration process in just 12 steps. Sound impossible? Roll up your sleeves and find out.

These 12 steps are intended to be a general guide of the order you’ll need to follow in your upgrade project. It’s likely there will be some tasks specific to your organization, and some steps may require additional work. Keep in mind that this tip assumes that you will move completely off of Exchange 2003 and will not run the server in coexistence with Exchange 2010.

Step 1. Verify you have met the prerequisites
Before you can begin deploying Exchange 2010, you must meet a number of prerequisites. Most of these requirements are associated with preparing Active Directory for the upgrade, but there are also some server-level requirements. You should verify that the following criteria have been met:

  • Your schema master must be running Windows Server 2003 SP1 or higher or Windows Server 2008.
  • Each Active Directory site where an Exchange Server will be installed must have at least one Global Catalog Server that’s running Windows Server 2003 SP1 or higher, Windows Server 2008 or Windows Server 2008 R2.
  • The Active Directory forest must be at the Windows Server 2003 forest functional level.
  • Domain controllers must run Windows Server 2003 SP1or higher, Windows Server 2008 or Windows Server 2008 R2.
  • Servers running Exchange 2010 must be running a 64-bit version of either Windows Server 2008 SP2 or higher or Windows Server 2008 R2.
  • Exchange 2010 servers require version 3.5 (SP1) of.NET Framework, IIS, Windows PowerShell 2.0 and Windows Remote Management 2.0. You may need additional components depending on the server role that you’re installing.
  • Prepare AD or run Schema Admin permissions to prepare AD automatically when you deploy the first Exchange 2010 server role.

Step 2. Run the Exchange Pre-Deployment Analyzer
Technically, this is an option step, though it is highly recommended. The Exchange Pre-Deployment Analyzer, which is shown in Figure 1, analyzes an existing Exchange environment and checks that you’re ready to upgrade to Exchange 2010. The tool analyzes the existing site topology and notifies you of any issues that may stand in the way of your migration.

Run the Exchange Pre-Deployment Analyzer prior to migrating to Exchange 2010

Figure 1. Though optional, running the Exchange Pre-Deployment Analyzer is a smart choice prior to deploying Exchange 2010.

Step 3. Deploy the Exchange 2010 client access role
Exchange Server 2010 uses five different server roles -- client access server, hub transport server, edge transport server, mailbox server and unified messaging server. Of these, you must install the client access server (CAS) role first. In some cases, the CAS may run on the same server as other Exchange Server roles. If this is the case, deploying all of the roles onto that server at the same time is acceptable. Microsoft has some basic instructions for deploying the CAS and other Exchange 2010 roles on TechNet.

Step 4. Install digital certificates
If you plan to use any of the external connectivity features associated with Exchange Server 2010, such as Outlook Web App (OWA), Outlook Anywhere or ActiveSync, you’ll need to provide the CAS with X.509 certificates that it can use for SSL (Secure Sockets Layer) encryption. Exchange 2010 is equipped with self-signed certificates, but these certificates are generally unsuitable for use in a production environment.

You’ll need to either purchase necessary certificates from a commercial certificate authority (CA) or generate the certificates manually using a Windows Server configured to act as an Enterprise CA. If you generate the certificates yourself, check that all clients are compatible with it. You can find more information on assigning certificates to Exchange on TechNet.

Step 5. Configure virtual directory settings
At this point, you’ve installed the client access server and assigned trusted certificate authorities to it for any ancillary applications. You should now provide Exchange 2010 with any external URLs for virtual directories that will reside on the CAS.

To do so, open the Exchange Management Console (EMC) and navigate to Server Configuration | Client Access. You’ll see a series of tabs that correspond to applications such as OWA and Exchange ActiveSync (Figure 2). Choose the tab that corresponds with the Web service you want to configure, right click on the virtual directory and select Properties from the menu. EMS will open a dialog box that lets you set internal and external URLs for the selected Web service.

Configure the Web services you want to use in the EMC.

Figure 2. Configure the Web services you'll be using in the Exchange Management Console.

Step 6. Installing the hub transport role
Once you’ve configured your virtual directory settings, the next step is to install the hub transport server role. Essentially, all internal mail flows through this role. Hub transport servers maintain message queues and apply transport rules to messages.

You have the option to install the hub transport server role onto a dedicated server or onto your CAS. If you install it on a dedicated server, you will benefit from improved security and server performance. Simply attaching the hub transport role onto the CAS can diminish performance and security; however, it’s an option if cost is an issue.

Performance can suffer if multiple roles are installed on a single server unless that server has adequate hardware resources to efficiently handle them. There is no direct security threat associated with combining server roles, but operating single roles can result in a smaller attack surface.

Step 7. Installing the mailbox server role
As its name implies, the mailbox server role hosts the Exchange mailbox server databases. The role can also host public folder databases; however, public folders aren’t required in Exchange 2010 unless you have clients within your environment that are running older versions of Microsoft Outlook. If your existing mailbox servers contain non-default public folders, you’ll eventually need to move those public folders to the Exchange 2010 mailbox servers.

Microsoft changed storage requirements with Exchange 2010. All previous versions of Exchange used single instance storage (SIS), meaning that even if a message was sent to 100 recipients, the server would only store it once within the database. In Exchange 2010, however, a separate copy of the message is stored for each recipient. As such, mailboxes likely will consume more disk space after you’ve moved them to Exchange 2010. Microsoft’s Mailbox Server Role Requirement Calculator features a tool that calculates the amount of storage space you’ll need.

Step 8. Change the offline address book generation server
The offline address book generator (OABgen.DLL), a subcomponent of the Exchange System Attendant, gives mobile users access to the address book -- even if they aren’t connected to Exchange Server. Since offline users cannot retrieve the global address list as they normally would, they can rely on the offline address book (OAB).

After installing the mailbox server role, you need to configure your architecture so that OAB generation occurs on an Exchange 2010 server. To do so, open EMC and navigate to Organization Configuration | Mailbox and select the Offline Address Book tab. Next, right click on the OAB and choose Properties from the menu to display OAB’s properties sheet. Go to the Distribution tab and select Enable Web Based Distribution and Enable Public Folder Distribution check boxes, as shown in Figure 3.

Open the Exchange Management Shell to make sure OAB generation occurs on an Exchange 2010 server.

Figure 3. Configure your architecture so that OAB generation occurs on an Exchange 2010 server.

Click OK to return to the main console screen. Next, click the Move link located under the Actions pane and follow the prompts to move the OAB generation process to an Exchange 2010 server.

Step 9. Installing an edge transport server
Microsoft recommends placing the edge transport server at the perimeter of your network to protect Exchange Server from Internet threats such as spam, viruses and other malicious attacks. Although recommended, this step is optional. If you are going to use an edge transport server, then it should neither be joined to a domain nor should it host any other Exchange server roles. You can find instructions for deploying an edge transport server at TechNet.

Because an edge transport server is isolated from the rest of your Exchange organization, you’ll need to create an edge subscription. The edge subscription process uses an .xml file to create a logical link between the edge transport server and the hub transport server. You can find instructions for performing an edge subscription at TechNet.

If you choose not to use an edge transport server, you’ll have to create a send connector to route mail from your hub transport server to the Internet. You’ll also need to modify the default receive connector to accept Internet mail.

Step 10. Physically moving user mailboxes to Exchange 2010
After you’ve installed and configured the necessary Exchange 2010 server roles, you’re ready to move user mailboxes from Exchange Server 2003 to the Exchange 2010 mailbox server. Although Exchange 2003 has tools for moving mailboxes, you must use the Exchange 2010 tools to create a move request.

Start by opening the EMC and navigate to Recipient Configuration | Mailbox. Select all of the mailboxes you want to move and click on the New Local Move Request link found under the Actions pane. A wizard will launch asking you where you want to move the mailboxes to and how you want to deal with corrupt mailbox data. Follow the prompts to complete the move request.

Step 11. Exchange public folder migration
Next, you’ll want to move public folders from Exchange Server 2003 to the Exchange 2010 mailbox server. Luckily, this process is quite easy.

Open the EMC and select the Public Folder Management Console option from the Toolbox. When the console opens, expand the Default Public Folders container and right-click on the public folder that you want to move. Then select the Properties command. When the folder’s properties sheet opens, go to the Replication tab and add your Exchange 2010 folder as a public folder replica, then click OK. After public folder data replication is complete, go back to the folder’s properties sheet and remove all of the replicas except for your Exchange 2010 server.

Step 12. Completing the upgrade to Exchange Server 2010
After you’ve migrated all data to Exchange Server 2010, you can complete the upgrade process. To do so, you’ll need to perform a few small tasks like entering a product key and enabling Outlook Anywhere. More important, though, you must remove all Exchange 2003 servers from your Exchange organization. Removing Exchange 2003 is fairly simple and requires that you verify that you’ve moved all resources to new Exchange 2010 servers. You must then use Exchange Control Panel’s Add / Remove Programs applet to uninstall Exchange


Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.

This was last published in July 2011

Dig Deeper on Exchange Server Deployment and Migration Advice



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.