To save you reading all those previous posts, here’s a recap for you:
Late in the evening of Sunday 4th March 2012, the testing phase was over. I had had feedback from our early adopters and, with all systems set to ‘go’, the first batch of production users were about to be migrated from Exchange 2007 into the heady delights of Exchange 2010. Over the course of that night these accounts tested the efficacy of my scripts and logging – which actually performed better than expected. Script processing was far faster than I could have dared to imagine.
The migrations continued each night, moving approximately 2500 mailboxes each night, for five nights each week.
By Monday 19th March, after three weeks’ worth of migrations, I had passed the halfway mark. The three-quarter mark was passed by the 23rd March and by the time I reached the end of the month over 99% of Nexus mailboxes had been successfully migrated.
April began with negotiation: within the remaining 306 Exchange 2007 mailboxes were 150 mailboxes belonging to one particular division which had been postponed due to sharing concerns. It took until the 16th April to resolve their issues before those mailboxes could finally be migrated. This took me up to the grand total of 99.8% completed. But at this stage I was entering the hard slog of problem mailboxes – the ones which had already failed to migrate at least once. The reasons for this were quite varied, starting from the ones which had (as it turned out) relatively straightforward corrupt messages, through to a pair of mailboxes where every migration attempt locked the user out of their mailbox for 24 hours. Resolving these last 150-odd mailboxes involved a significant amount of communications both with users and their IT support staff to work through the many lists of corrupt mailbox items. I owe a debt of gratitude to my colleagues – and to the users themselves – for their assistance with this part of the work.
At the same time I had to begin recovering space from the Exchange 2007 servers by defragmenting databases. Migrating users from Exchange 2007 had created vast swathes of whitespace within that system’s stores so our backup software still saw the databases as enormous. In order to ensure that both versions of Exchange could still be backed up successfully in the limited time available each night a defrag was the obvious solution. After my initial (and very time-consuming) manual approach to this I developed a script to dismount the empty databases, defragment them with ESEUTIL and then remount them. The sole remaining manual step was to kick off a full backup so that our schedule of full and incremental overnight backups didn’t get confused.
My inability to successfully move the final three users required vendor assistance but, after a number of dead ends, and time pressure looming, a mailbox backup and restore emerged as the only successful way to migrate them across. The last of these users was migrated in this way this afternoon.
I therefore pronounce that, as of 2:48pm this afternoon, Exchange 2007 is officially no longer servicing any production Nexus mailboxes.
Let the decommissioning commence!
Hi Matthew,
Great blog… Just embarking on our Ex2010 design and migration planning. It would be great to hear from your experiences and thoughts on how to implement. I see your using a two site config, similar to what I’m considering.
A couple of questions:
1. I’ve always found benchmarking the system upfront a good idea but how does your system perform compared to the Jetstress results you had prior to migration?
2. I’m thinking if ‘multi-rolling’ my servers (CAS/HT/MB). Where there any reasons at the design phase why you choose not to ‘multi-role’ your servers and go for separate CAS/HT/MB roles?
3. (just thought) I currently choose DPM for our Ex2007 solution and have got DPM2012 licences. What solution do you use to backup your Ex2010?
I’d love to have a meet up in Oxford to have a chat if you’re free one afternoon?
Well done on your completion enjoy Ex2010 until 2013 😛
Caleb
Hi Caleb,
Thanks for your comments. I’d be happy to share some of my experiences.
To answer your questions:
-The performance was difficult to compare accurately with Jetstress until we had a reasonable number of mailboxes moved. We’re only really now at a stage where the figures will be properly reliable. But the use of pessimistic estimates at the planning stage has meant that real-world performance is, if anything, better than anticipated.
-We chose to separate the roles for a number of reasons. I’m wary of multi-roles on mailbox servers although I’d not be opposed to combining CAS and HT, in a smaller environment. It helps us to keep them separate as we have had some issues with mail hygiene software very occasionally crashing a service – with separate functions that lessens the likelihood of user impact.
-I’m a big fan of DPM and if we were starting afresh I’d certainly be considering it. However we’re in the (fortunate) position of having a dedicated backup team here. We’re therefore using TSM but they, and I, have an intent to move to a more efficient de-duping system in the near future.