Computing Research: Microsoft Exchange 2010 – taking the plunge

By John Leonard
18 Jul 2012 View Comments

Make a comprehensive list of the tasks to be performed and add them to your timeline. Scheduling the migration is an aspect that requires careful thought. Because of the downtime associated with the mailbox migration event, try to schedule user transitions during non-business hours, and be sure to allow sufficient time for each tranche of moves. Mailbox migration was the number one cause of difficulty reported in the Computing survey, and a large mailbox can take a long time to move – over an hour in some cases (figure 2).

2er2[Click image to enlarge]

Other tasks to schedule include: end-user communications, set up and tracking of migration events and coordination of training. You will also need to ensure that staff and managers are able to work nights and weekends during the migration.

Set up milestones and reporting procedures so that the business is kept informed at each stage of the process. As well as keeping the business abreast of progress, this will allow you to track who has been moved, what exceptions you have had to cater for and generally to maintain full control of the migration itself.

Calculating storage

Your idealised design will enable you to calculate storage requirements, identified as one of the main problem areas. The increase in the size of the Exchange 2010 database seems to be the main issue here, as well as integration with existing storage systems (figure 3).

[Click image to enlarge]

To calculate storage requirements, download the Requirements Calculator from the Microsoft Exchange Team website. This migration tool can be used to calculate storage requirements, the capabilities to handle peak loads, the type of CPUs and how much memory is required on the environment. Be aware of the requirement for log volumes when moving large amounts of data because these will not be truncated at first.

Unlike previous versions, Exchange 2010 routes all client traffic through the client access servers (CAS), increasing the load on the CASs. This means that it is likely that you will need to provision additional servers (64-bit, Windows Server 2008 R2) and memory to run the new Exchange system.


Once plans are in place, experts advise that you spend ample time testing the process. IT teams, the support desk and any service providers should be involved, and the testing itself should be as close to real-world scenarios as possible.

The equipment calculated to meet the requirements for the idealised endpoint design should be purchased and used in the lab tests. If the test migration shows that additional equipment is required, it can be purchased in a planned manner rather than in a state of distress part way through a live migration. Test migrations will generally  be erased prior to the real migration.

Testing allows engineers to become familiar with new technologies, situations and processes and to identify gaps in the workflow before these create problems for the user base.
Failing to successfully run the migration process in a controlled environment before the live migration is to put the project at a high risk of serious errors and delays.


Once all the preparatory work has been done it is time to install the core Exchange 2010 Server. This is a reasonably straightforward process once the server has been set up with of Windows 2008 64 Bit R2 and other necessary supporting software, namely .NET, RSAT Tools, IIS and the Windows Desktop Experience.

When the installation is complete and tested, you need to perform some migration and configuration tasks including setting up the CAS, Hub Transport (HT) and mailbox roles, plus OWA if you are using it. Exchange ships with PowerShell, a command-line shell and associated scripting language, for such administration purposes. There are also a variety of third-party applications on the market.

During installation of the Mailbox Server a new Mailbox Database and a new Public Folder database will also be automatically created on the Mailbox Server. The contents of existing public folders need to be replicated to the new location using the PowerShell toolkit.

If you are migrating from Exchange 2003 it is important to note that routing groups and administrative groups were eliminated in later versions of Exchange, starting with the 2007 version. Some readers reported this as a cause of difficulties. The key is to ensure that your Active Directory (AD) is set up and working properly before you start moving data.

Also important to note is that all roles (bridgehead, frontend and backend) in Exchange 2003 (or the 2007 server roles in Exchange 2007) need to remain intact until all users have been moved to Exchange 2010.  

Reader comments
blog comments powered by Disqus
Windows 10 - will you upgrade?

Microsoft has made an early version of Windows 10 - its next operating system - available for download. The OS promises better integration and harmonisation across platforms, including mobile and desktop. Will your business be upgrading?

39 %
26 %
14 %
21 %