View from the inside: a challenging Exchange migration
To upgrade or not to upgrade…
System upgrades, whether we like them or not, are a necessary part of our technological world. However, in an effort to save costs, many organisations hold back from rolling out new technology. When an upgrade is finally approved, multiple complex systems are often upgraded all at once. Multiple upgrades increase the risk of complicating the execution or lost user productivity because of delays, or at worst - the loss of critical data during the migration process. In this post, I’ll share with you the story of an organisation that was forced to upgrade too many IT assets at once because they did not have the resources to keep up with regular maintenance projects. We’ll then take a look at if the migration was a success.
A challenging migration
Firstly, I’ll paint a picture of the situation; a large service and product organisation with multiple international offices took on an Exchange 2010 migration project that would affect all of its locations. The migration scope was 20 offices, three network domains, and over 6,000 user mailboxes, and included a Blackberry® Enterprise Server (BES), Outlook Web Access (OWA) services, plus the introduction of Microsoft® Forefront® servers to the infrastructure.
The client explained that at the time the biggest challenge in planning the project was a delayed Windows® Server Domain Active Directory (AD) consolidation that had been in progress for almost a year. Due to the rapid expansion of the business, many of the satellite offices had set up their own domains with only a trust relationship with the domain of the business headquarters. As a result, users in those satellite offices could not log on to the headquarters domain and access corporate resources, even when those users had been added with access rights.
More shortcuts = more risk
Over the years, shortcuts were taken at this organisation to get user access to the corporate business systems. Some of these quick fixes increased the complexity of user accounts and even introduced IT security risks. In one example, a satellite office was constantly having access issues but rarely received IT resources to resolve the issues. The office manager was so frustrated that he took matters into his own hands and ordered a second Internet line to the office; setting up a connection with the company’s headquarters and remote controlling a computer to access the organisation’s CRM system.
At great risk, the low encryption connection was accessing the Internet from the satellite office and re-entering the organisation through an unused network port. When the IT security department found the unauthorised connection, it was shut down immediately and again, this satellite office was without business system resources and had to re-open the original job ticket with IT.
Due to these undocumented fixes the IT engineer working on the AD design wanted to start over and rebuild the systems from the ground up. Unfortunately, with the number of user accounts and dependencies the organisation had within its network, a complete reconstruction was not an option.
The IT department started a systematic collection of all of the server systems in each office and began documenting an upgrade process that would complete the AD move and lay the foundation for the Exchange 2010 migration. The impacts were larger than originally estimated and the entire project took 18 months - six months longer than planned.
One of the more intricate migrations was for the BES system. There were not enough resources to perform the migration for the entire employee population and as a result, specific instructions were written for users to manually complete the mailbox update on their mobile phones.
If the process was not performed exactly as written, the BES mailbox synchronisation process would work in reverse and all of the user’s archived email data would be lost. Inevitably, some users lost data but fortunately, prior to the upgrade, the IT department’s business continuity plan accommodated for user error and multiple backups were completed at various stages in an effort to minimise data loss.
Was it successful?
In this situation I suggested that this client use Ontrack PowerControls for Exchange to extract the user mailboxes and copy them during the test migration, making the entire process quicker and easier. Additionally, the client utilised this DIY tool to quickly access archived tape media that contained Information Stores, to extract messages from backups for those users who had not followed the BES migration instructions.
This project was long and tedious, and it required diligence and patience to work through all of the phases and milestones. Yet with savvy IT staff and the use of additional tools to get the job done, this migration was a success.
Let me know your experiences when migrating Exchange data in the comments below, or you can tweet @DrDataRecovery