Exchange 2007: Leaving Old Technology in the Past
A few weeks ago (10/31/11) our DEWEY cluster suffered a major outage at the result of old conflicting RAID policies that led to the dirty dismount of 50% of the DEWEY databases. Immediately, our team started the recovery process, which unfortunately took longer than ever expected (More details @ https://www.exchangedefender.com/noc) and prompted our side to start developing a new solution for DEWEY users to restore and maintain the expected service availability and reliability.
Lets be forthright…DEWEY has been somewhat of a nuisance not only to our staff, but also to our partners and your users.
Overall, Exchange 2007 was a drastic leap and improvement from Exchange 2003, but still lacked many features for service providers or any rapidly expanding company such as the ability to properly scale the solution and implement additional failovers after initial deployment. In comparison, I think of Exchange 2007 as Windows Vista – it brought a lot of new features and easier management from 2003, but after a year of management it feels like a bad tease.
Over a year ago, we decided to immediately start offering Exchange 2010 as soon as it RTM because we felt we hit the ceiling in terms of scalability with Exchange 2007. Sure, we could add more CAS servers and MBOX servers, but that would eventually end up with partners having multiple configurations to keep track of for clients in the same company. Taking everything into account Exchange 2007 was no longer the road we traveled down for new deployments.
Going back to DEWEY, we started experiencing more frequent issues in terms of reliability over the past six months. Between services failing to respond in a timely manner or even worse, not responding at all we knew we had to provide a solution before our partners clients threw up their hands to say “I’m done!”.
Upgrade, Upgrade, Upgrade
In order to provide a solution we must keep a few essential components in mind:
1. The upgrade must be seamless with no mail loss and no major service interruption.
2. The upgrade must be automated. We can’t expect partners to import/export data or reconfigure Outlook.
3. The upgrade must be scheduled so partners are kept in the loop on the migration progress.
4. The upgrade must be flexible for partners who want to slowly migrate or for partners who want to immediately move.
Unfortunately, Exchange 2007 does not provide the ability to seamlessly move users directly to any remote Exchange 2010 cluster (i.e. Rockerduck), but we can upgrade to a local 2010 cluster, then move the client to ROCKERDUCK.
The Solutions is Here…
In the past few weeks we have deployed and successfully tested a 40 user migration from 2007 DEWEY to 2010 ROCKERDUCK with very minimal effort on the partner’s end. Below is a rough overview of the process which was designed for a 2 week migration for clients:
1. Partner adjusts autodiscover CNAME record to NEWDEWEY (2010).
2. Move requests get created from 2007 DEWEY to 2010 DEWEY (Week 1, Monday).
3. Users on DEWEY will remain on 2007 throughout the work week.
4. Move requests will be finalized on Friday evening. Users will now be serviced on 2010 DEWEY (Week 1, Friday).
a. Users with BES devices will remain on 2007 until the final move to ROCKERDUCK.
5. Users come in on Monday, restart Outlook.
6. Move requests to ROCKERDUCK are created (Week 2, Wednesday).
7. Partner adjusts autodiscover record to point to ROCKERDUCK (Week 2, Friday at close of business).
8. Move requests will be finalized Saturday evening (Week 2, Saturday).
9. User comes in on Monday, selects “Repair account” on ‘Email Accounts’ list. User is now serviced on ROCKERDUCK.
10. Users re-setup ActiveSync and any Blackberry Enterprise Server accounts.
With the above outlined process users should not see any service interruption nor will users have to recreate their Outlook profiles.
Travis Sheldon
VP Network Operations, ExchangeDefender
(877) 546-0316 x757
travis@ownwebnow.com