Computing Research: Microsoft Exchange 2010 - taking the plunge
John Leonard relays some practical advice based on expert best practice and readers' experience
To read part one of this research, please click here
While there are numerous advantages to be had by migrating to the latest version of Microsoft's Exchange collaboration and email package, the pivotal importance of email to the modern enterprise means that any errors in the migration that result in downtime can have grave consequences. It is vital, therefore, to plan carefully to ensure that this occasionally complex process goes as smoothly as possible.
In February 2012, Computing surveyed 200 IT decision-makers in large organisations, about half of whom had migrated or were migrating to Exchange 2010.
We asked them specifically about those areas that had caused most problems, and the results can be seen in figure 1 below. The most notable thing about this list is that the vast majority of these issues can be dealt with in the planning stage.
[Click image to enlarge]
The migration process
A typical migration process can be broken down into a few basic steps:
• Research, prepare and plan
• Install and configure Exchange 2010
• Migrate the data
• Install certificates
• Set up Outlook Web Access OWA
• Decommission legacy system
There will be variations, of course, depending on the legacy platform and the type of system you are migrating to - a hybrid Exchange/Office 365 setup is one possibility.
PreparationTo be forewarned is to be forearmed. Before the migration starts you need to be sure of your roadmap, your requirements in terms of personnel and infrastructure, a realistic timeline and a good idea of the challenges you are likely to face. It is very important that you formalise this process using some sort of project management tool.
The first stage is research. Before any migration you need make sure you have the following information to hand:
• User names
• Departments or business groups
• User office locations
• Out-of-office settings
• Staff responsible for maintaining group calendars
• Different Exchange 2003/2007 and Exchange 2010 sites
• Mailbox sizes
• AD groups and distribution lists
• User phone numbers (for SMS notifications)
As part of the information-gathering process you should prioritise a floor-walk to find out where the data resides, what format it is in, who is actively using it and which features and services are most valued.
Break users into groups of usage patterns, such as the time of day they log on, peak activity times and whether they use mobile access etc. Schedule the migration to have the minimum impact on each group. Reschedule migration if the timing is not convenient for the users.
Idealised design
Based on the knowledge gained during the information-gathering stage, the next step is to produce an idealised design. This should be how you imagine your Exchange deployment would look in a perfect world, if you could start from scratch. It should also map out what data you are going to move, which will allow you to plan hardware and networking requirements more effectively.
Once this design is in place you can start to build the migration process, to plan the steps you need to take to reach your idealised design.
Computing Research: Microsoft Exchange 2010 - taking the plunge
John Leonard relays some practical advice based on expert best practice and readers' experience
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).
[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.
Testing
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.
Installation
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.
Computing Research: Microsoft Exchange 2010 - taking the plunge
John Leonard relays some practical advice based on expert best practice and readers' experience
Mailbox compatibility between Exchange versions was reported as a significant issue by Computing’s survey respondents (see figure 1). The reason is that Exchange 2010 CAS, HT and mailbox servers are not backwards compatible with Exchange 2003/2007. This means that OWA users on earlier versions need to continue to access their mailbox on the Exchange 2003/2007 backend server until their mailbox has been migrated to Exchange 2010, after which traffic will be routed through the Exchange 2010 CAS server to their mailbox on the Exchange 2010 Mailbox server.
High availability
The pivotal role of the CAS servers (or arrays) means that to maintain high availability it can be advisable to introduce multiple CAS servers in each AD site as well as load balancing the protocols and services provided by this role.
The range of HA solutions set up by survey respondents is shown in figure 5.
[Click images to enlarge]
One big change in Exchange 2010 compared with previous versions is the high availability and disaster recovery functions of the Mailbox Server role. Previous replication functions no longer exist in Exchange 2010, having been replaced by the concept of Database Availability Groups (DAGs).
DAGs provide a software controlled layer of virtualisation and high availability, offering the capability to replicate multiple copies of mailboxes across servers. Before moving mailboxes to the DAGs, check your DAG replication and test failover and failback of the Exchange 2010 Mailbox Servers.
Migrating mailboxes
Scheduling for migration has to be set up and run manually as does completion tracking and reporting, so schedule time for these elements of the process.
User mailboxes will be inaccessible for a brief period when they are moved to the new environment. However modern tools enable migration to occur in background so the user can go on using the old mailbox while data is migrated until the decision is made to switch them to the new environment. For example, if migrating from Exchange 2007 to 2010 the ‘suspend when ready’ feature can be used do the majority of data migration while the user is online with the final five per cent being done when the user is off-line.
Since one of the main migration challenges is the sheer amount of time taken to move mailboxes to their new home, all possible measures should be undertaken to eliminate any drag on the process. Tips for faster migration include the following:
• Ensure the two servers are as close as possible to each another on the same subnet
• Reduce WAN bottlenecks – isolate the servers to ensure that backups of other servers on the same backbone do not slow the migration
• Turn off anti-virus software on both servers as virus scans will use resources
• Also make sure your regular scheduled backups are turned off
• Launch the migration tool from the new server rather than the old one
Migration team leaders will have to use their judgement when migrating large mailboxes – the definition of large will vary from one organisation to the next and could be anything from 1G to 5G and above.
Computing Research: Microsoft Exchange 2010 - taking the plunge
John Leonard relays some practical advice based on expert best practice and readers' experience
If a large number of oversized mailboxes need to be migrated, consider the time and performance impacts on the existing system. Migrating large volumes of data can degrade performance for other users. It may make sense to delete or archive older material before migrating these mailboxes.
If a user – such as an executive PA - has mailboxes which comprise numerous calendars and lots of contacts and groups it will take longer to migrate than the same size mailbox that is just mail items.
Locating and importing Personal Storage Tables (PST files) can be tricky, as these are likely to be located on PCs and laptops dotted around the organisation. There are Exchange PowerShell scripts to help with this. Alternatively a range of third-party solutions is available.
Certificates
Although hardly mentioned as a potential hurdle by those respondents that were still at the planning stage, installing certificates came quite high on the list of bugbears for those who had completed a migration. There appears to be a degree of confusion about which certificates are required and where, with some people believing that each named element needs its own certificate.
However, while organisations may require many site names for AutoDiscover, Active Directory, ActiveSync, OWA, etc, they do not need a certificate for each of these.
The requirement is for only one certificate per site. Internet-facing sites require external certificates; internally facing sites require internal certificates. So if the organisation has 50 internal sites and one external site, acquire a single third party certificate for the external site, and raise an internal certificate authority (CA) and create and deploy certificates for the internal sites using this CA.
Experts advise firms to obtain a certificate for a single host that contains Subject Alternate Names and install that using the Exchange Management Console or PowerShell. The Exchange Server Deployment Assistant2 will allow the migration team to step through what is required, such as certificates and where they should be installed.
Outlook Web Access configuration
Getting OWA to function during the migration can be a source of frustration. This is because the CAS installed as part of the Exchange Server 2010 package needs to be configured to redirect users to the legacy front-end. When a user connects to Exchange Server 2010 CAS for OWA and the mailbox is still on Exchange 2003/2007, the client will be redirected to the old 2003/2007 front-end server.
Once the clients have been updated the redirects are removed and the DNS will direct the OWA traffic to the new front-end server.
Moving from Lotus Notes
About five per cent of the respondents to Computing’s survey had migrated from a Lotus Notes environment to Exchange 2010. This is certainly a more complicated proposition than moving from a legacy version of Exchange.
Computing Research: Microsoft Exchange 2010 - taking the plunge
John Leonard relays some practical advice based on expert best practice and readers' experience
The main issue here is one of available skills. It is relatively rare for professionals to be well versed in both Exchange and Lotus Notes.
For this reason a realistic test environment is even more essential when migrating from Notes as it allows migration staff to make themselves thoroughly comfortable in the new environment. As well as this, a staging server should be set up, to which mail files can be replicated in the first instance. Once there, any errors can be removed without affecting the production environment.
There are other issues too. Notes files can grow to enormous sizes and migration teams will have to judge how much to keep.
There may also be discrepancies between the functionality that Notes users are familiar with and what is possible in Exchange. For example, Notes is a powerful tool for creating workflows, and not all aspects of this functionality can be replicated in Exchange. The migration team should therefore take pains to discover exactly what people are doing in Notes, to ensure that migration to Exchange is not a backward step.
Decommissioning
Once everything has been migrated and thoroughly tested, the legacy environment can be removed – although most people we spoke to leave it in place for at least a few days as a failsafe in case they need to roll anything back.
The procedure may differ according to the legacy system, but it goes something like this. Using the Exchange Management Shell you first need to remove the interoperability connector that is routing traffic through the legacy front-end. Next remove the legacy front-end server using the Add/Remove Programs function in Windows. The Recipient Update Service is the next to go (using Exchange System Manager), and finally the legacy Mailbox Server can be removed.
Third-party help
As we have seen, Migrating to a new version of Exchange is a stepwise process. While not particularly complex, it is time-consuming, labour-intensive process and there are plenty of things that can go wrong, especially in the case of complex distributed environments or when migrating from another vendor. If you do choose to go it alone, there are many excellent online blogs and articles and walk-throughs to help you with the details, as well as community resources on Microsoft’s website.
However, for many the scale of the task combined with the consequences of failure lead them to turn to expert help. About half of the survey correspondents elected to employ some form of third-party assistance during the migration process (figure 6).
[Click image to enlarge]
• This article is based on an email survey of 200 IT decision-makers in large organisations, and on questions posed during a subsequent web seminar in March. We are grateful for the assistance of specialists from Exchange experts Mimecast and Binary Tree in providing detailed information about the migration process.
There is also an online Q&A session where more detailed questions are answered. If you have questions about migrating to Exchange 2010, or feel you can help others who are, please visit www.computing.co.uk/2190452.