Since the launch of Microsoft Exchange 2010, organizations looking to update their infrastructure with more energy and cost-efficient servers are rapidly adopting the messaging platform, making it the dominant selection in the messaging and collaboration marketplace.
There are many benefits that come with adopting the latest version of Microsoft Exchange 2010, including a streamlined installation process, excellent online resources, enhanced information security and improved compliance features. What’s more, the new servers are providing organizations with more efficient hardware in terms of cost, energy and process.
Upgrading from legacy systems is presenting a number of challenges for IT personnel, though. The continued growth of email and email-associated items can be a major migration hurdle, particularly for those that operate globally. 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.
Whether upgrading from Microsoft Exchange 2007, the older 2003 version, or moving over from a non-exchange platform, IT personnel managing the migration have a number of security and compatibility issues to address if they are to ensure a seamless and efficient transition:
Migration Scenarios
The simplest scenario involves a transition from Exchange 2007 to Exchange 2010 where there is no consolidation and all mailboxes are within a single Active Directoryforest. 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 5.5, Exchange 2000 or Exchange 2003 — none of which have a direct migration path to Exchange 2010. In these instances, Microsoft’s recommended method would be to first transition to Exchange 2007 and then transition again to Exchange 2010.
The final scenario is one of consolidation or total renewal. 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; centralization into regional data centers; 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 generalize about the tools needed for migration; however, it is often true that third-party tools can save both time and money.
For each scenario, there are a series of best practices that organizations can follow to ensure a seamless transition:
Using Microsoft Tools
Intra-organizational transitions from Exchange 2007 follow a well-understood pattern. First, Exchange 2010 is installed on either Microsoft Windows Server 2008 or 2008 R2 64-bit edition, and often on new hardware or perhaps a virtualization 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 (OWA) and mobile devices and to reroute any users still on Exchange 2007 to the relevant backend Exchange 2007 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 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 2007, and when moving from Exchange 2007 SP2 to Exchange 2010, can also move mailboxes online. 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. However, the online mailbox move is not available for the transition from Exchange 2003.
Using Third-party Tools
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 2007 and then Exchange 2010 it is considerably easier and less time-consuming to using certain tools on the market today. Certain tools can extract data directly from the legacy Exchange system database (EDB) files and import them directly into the new Exchange 2010 system, while 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 a technology to import the data into the new centralized 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 technology solution to perform complex searches based on criteria such as date range and to migrate only the selected data is a significant advantage.
In legacy versions of Exchange Server we could use PFDAVAdmin to manage calendar permissions, or alternatively the 3rd party tool SetPerm.
Exchange, Powershell, AD & Azure Tips 