After a brief break from blogging, I was back in the studio recently recording more videos to answer questions about Exchange design decisions.
Now most of the time I talk to customers about new functionality that we have added to Exchange, and for the last few blog entries I have focused on some of these changes related to storage and archiving.
In this entry I wanted to cover another topic which gets asked about a lot – why did the Exchange team not include an in-place upgrade option in the product in recent versions? Is it that the Exchange team is filled with a bunch of lazy developers or are there valid reasons for doing this?
I was going to stop there and let you watch the video (which I encourage you to do!) but I thought I’d give you a sneak peek into what the answer is, so here are some of the major points:
The video covers a lot, including the online mailbox move feature. I'm interested in any questions or comments these answers generate. Let me know what you think.
My general observation is that Microsoft make "substantial changes to [their] architecture" to implement things that clearly can't be fixed in the previous version. Remember active-active clustering, which had a dismal reputation? Rather than fix it, it was just removed, and came back at a later date along with a 'substantial' architecture change.
Remember how Microsoft used to bang on about Domino taking up more disk space because of the separate mail box architecture? Maybe, but if someone else's mail box screwed up at least mind wouldn't be affected. I've been onsite with a prospective customer when the announcement went out - "sorry everyone, no e-mail until tomorrow". Now Domino handles the attachments in a more storage-friendly fashion while the mail boxes are still handled in that resilient way - meanwhile Exchange seems to have gone in the opposite direction in a bid to stabilise those all-affected corruptions. That Domino capability came in with version 8.5 which was a straightforward in place upgrade.
"The migration model is well suited to most organizations" - I know of a company with 130 Exchange servers. The lack of in-place upgrade makes the process a mind-boggling effort. So I guess when you say "most" you're not including that customer.
"Certainly to fully take advantage of the changes in the release requires rethinking the hardware design" - only if your solution of choice ends up being deficient on the up-to-date hardware. Don't assume that every e-mail solution falls into this category, because you'd be wrong.
Thanks for all your comments -- I've just published another blog entry to answer many of the issues which were raised. blogs.technet.com/.../responding-to-migration-vs-in-place-upgrade-comments.aspx
Garbage. In place is about making things simple. All they have to do is make a new scheme and database based on the old information. The devs are lazy and no-too-sharp and they want to charge for a new product without helping out the people with the old generation.
I 100% reject no in place upgrades, even with virtualization and ll the rest of the rubbish going on. Nothing changes. The User is being told we have to endure pain for the greater good. All the time. In every direction.