Pitfalls and pathways to success
16 August 2010
Adoption of Exchange Server 2010 is set to accelerate significantly, according to Phil Bridge (above) and Nathan Winters (below)
Phil Bridge of Kroll Ontrack and Nathan Winters of the Microsoft Messaging and Mobility User Group discuss Exchange 2010 migration and the potholes, pitfalls and pathways to success.
With the imminent release of Microsoft Exchange 2010 SP1, adoption of Exchange Server 2010 is set to accelerate significantly. By 2011, we expect Exchange 2010 to take a stronghold in the messaging and collaboration marketplace, picking up where Exchange 2003 left off.
The majority of Exchange 2010 early adopters are organisations looking to complement hardware refreshes with the new version of Exchange, most likely moving from Exchange 2003 to 2010 to take advantage of the improved architecture, security and performance of 2010. Meanwhile, those slower in migrating to Exchange 2010 will be made up primarily of organisations that have already made the investment in deploying Exchange 2007 and 64-bit hardware.
Regardless of implementation timelines, the organisational goals seem clear: update servers to more efficient hardware in terms of cost, energy and process – and/or extract additional value from recently refreshed hardware and capitalise on the architectural improvements in Exchange 2010, which will form part of an overall unified communications strategy. On top of this, the enhanced information security and compliance features of Exchange 2010 provide a compelling reason for many to move platforms.
Exchange 2010 offers a streamlined installation process, which when combined with excellent online resources gives IT departments confidence to progress with deployment. The next and arguably greatest challenge is the actual migration (or ‘transition’) of an organisation’s data.
The continued growth of e-mail and e-mail associated items can be a major migration headache, particularly for those that operate globally. Business continuity has never been so important. The huge rush to consolidate data can make even the most experienced systems administrator or systems architect go weak at the knees when faced with an Exchange migration task. The situation may be further hampered in the current economic climate where downsizing or consolidation present complicated data integration challenges, set against the backdrop of significant budget constraints and an overworked, under-resourced IT staff.
The remainder of this feature touches on various migration scenarios and explains how different tools can help get the job done.
The process for moving to Exchange 2010 will vary depending on your organisation’s current platform. There are certain scenarios, which return time and again. The simplest is a transition from Exchange 2003/07 to Exchange 2010 where there is no consolidation and all mailboxes are within a single Active Directory forest. In the vast majority of cases this can be handled by the tools Microsoft provides as part of Exchange.
At the more complex end of the scale, migration from a non-Microsoft Exchange platform will almost certainly require third-party tools. This is also likely to be the case if you are migrating from Exchange 2000 or Exchange 5.5 – both these versions have no direct migration path to Exchange 2010. In these instances, Microsoft’s recommended method would be to first transition to Exchange 2003 and then transition again to Exchange 2010.
The final scenario is one of consolidation or total renewal – both of which present similar challenges. Data often needs to be moved across WAN links and mailboxes are potentially in multiple Active Directory forests. This situation can occur for a multitude of reasons: downsizing due to economic hardship; mergers and acquisitions; centralisation into regional data centres; moving to a new, clean Active Directory forest either as part of a hosted or managed service; or as the basis for a rollout of a new wave of technology. In these cases, it is hard to generalise about the tools needed for migration; however, it is often true that third-party tools can save both time and money.
Having outlined common migration scenarios, let’s discuss how to deal with them.
The Microsoft tools route
Intra-organisational transitions from Exchange 2003/07 follow a well-understood pattern. First, Exchange 2010 is installed on either Microsoft Windows Server 2008 or 2008 R2 64bit edition, and often on new hardware or perhaps a virtualisation platform. As part of the Exchange 2010 installation, the existing Active Directory is prepared for Exchange 2010. Once installed, Exchange 2010 is configured to take over the external Web access clients such as Outlook Web App and mobile devices and to reroute any users still on Exchange 2003/07 to the relevant backend Exchange 2003/07 server. Mail routing is established between the old and new systems, and services such as address book generation are moved to Exchange 2010. At this point co-existence is established and data migration begins.
Data migration during the transition from Exchange 2003 or 2007 is controlled from the Exchange 2010 management console (or management shell for scripting aficionados). A new feature, ‘Move Requests,’ makes use of the new architecture in Exchange 2010, specifically the Exchange Mailbox Replication Service. This service carries out all mailbox moves from Exchange 2003 and 2007, and when moving from Exchange 2007 SP2 to Exchange 2010 can also move mailboxes online. In other words, for the majority of the migration, workers can continue using Outlook as normal with only a short period of disruption right at the end of the move. Sadly the online mailbox move is not available for the transition from Exchange 2003.
Using third-party tools
In the more complex migration scenarios there is often a case to use third-party tools, which can save both time and effort. Third-party tools can often provide alternative migration routes to those available with Exchange 2010 native tools.
In a migration from a non-Exchange platform, an initial step is to build the Microsoft infrastructure. This will inevitably involve directory services work, to ensure that all mail users are represented in an existing or new Active Directory. At that point a new installation of Exchange 2010 can be carried out. Generally, co-existence (for example sharing calendars between systems) other than simple mail flow is a painful process and should be avoided. Microsoft no longer provides tools to migrate data from non-Exchange mail systems, so in this case reliance on third-party tools is essential.
When migrating from old Exchange versions or consolidating systems, perhaps as a result of a restructuring process or merger, there are several considerations. With an Exchange 5.5 or 2000 migration scenario, given that there is no online mailbox move facility and no direct path to Exchange 2010, instead of first transitioning to Exchange 2003 and then Exchange 2010 it is considerably easier and less time-consuming to use a tool such as Ontrack PowerControls. This third-party tool can extract data directly from the legacy Exchange system database (EDB) files and import them directly into the new Exchange 2010 system, whilst also creating new mailboxes on the fly if required. This would also be an appropriate method if as result of a merger, data needed to be moved from an acquired Exchange system.
In Exchange 2010 the ‘Move Request’ feature supports moving mailboxes from Active Directory forests other than the local one where Exchange 2010 is installed. However, in any consolidation scenario, WAN links may be an issue. If for example you were consolidating several remote servers into a central location and needed to move terabytes of data over a WAN link, the process would be extremely time-consuming. In such scenarios, it would therefore be simpler to ship extracted copies of the EDBs on hard drives to the central location, and use Ontrack PowerControls to import the data into the new centralised Exchange system.
Finally, with any of the migration scenarios described above, there is potentially a need to migrate only a select percentage of the data. This could be because you are trying to avoid the migration of redundant or end-of-life data, or because new data has been generated while performing an offline migration from a point-in-time snapshot of the source system. Having a tool such as Ontrack PowerControls, which can perform complex searches based on criteria such as date range and migrate only the selected data, is a significant advantage.
As you can see, there are a wide variety of migration possibilities to get your organisation to Exchange 2010. The key to any successful Exchange migration is planning and testing, and ensuring that you make use of the most appropriate tools for the job.
Phil Bridge is managing director of Kroll Ontrack’s UK data recovery services. Kroll Ontrack offers Ontrack PowerControls, which provides data management for Microsoft Exchange and SharePoint.
Nathan Winters is the founder of the Microsoft Messaging and Mobility User Group UK, which holds regular meetings to discuss topics related to Exchange. In 2007, he was named a Microsoft Most Valuable Professional. He is currently the unified communications lead at Grey Convergence, a specialist Microsoft partner for unified communications and collaboration.
Add a comment