News Stay informed about the latest enterprise technology news and product updates.

An early adopter explains Exchange Server 2010 benefits and troubles

One Exchange Server 2010 early adopter and implementer shares his thoughts on organizational and user benefits, cost savings and migration gotchas in this expert Q&A.

Rand Morimoto, president of Convergent Computing, knows his way around Exchange Server 2010. He has participated in the early adopter program for almost two years and has helped implement the product in roughly 40 client environments. Morimoto shares his experiences in this interview and in his recently published 1,400-page book on the subject, Exchange 2010 Unleashed.

What are the biggest benefits for early adopters of Exchange Server 2010?

Rand Morimoto: The biggest benefit that organizations found was the ability to address two or three issues at once. By this I mean that most organizations have high-availability and disaster recovery projects on the table because downtime is no longer acceptable in IT, let alone in email.

In the past, meeting high availability and disaster recovery requirements was impossible without using expensive third-party products. Exchange Server 2010, with the new database availability group (DAG) feature, provides both high availability and disaster recovery right out-of-the-box. This gives organizations local failover as well as failover to another data center across the country or across the world. This keeps mail flowing and allows users to connect and reconnect to their mail, even in the event of a server, site or continental failure.

Most organizations also have projects around email archiving and regulatory compliance. These have also been included in Exchange Server 2010. Out-of-the-box archiving gets mail out of users' mailboxes while keeping it in the Exchange environment for e-discovery and compliance.

Where are early adopters of Exchange Server 2010 seeing the biggest cost-savings?

Morimoto: With the new DAG, email archiving and new ways of implementing storage, organizations have been able to save tens of thousands to hundreds of thousands of dollars because they didn't have to buy third-party products to supplement what they had previously.

For example, we had one organization that was buying high-speed, expensive network storage for Exchange Server. It was planning to spend $1.1 million on storage and replication technology for high availability. Instead, it got what it needed with Exchange Server 2010 out-of-the-box for $33,000. It went live with an implementation in July and August 2009. So the company actually saved a ton of money with their Exchange Server 2010 implementation.

We worked with a smaller organization of 200 people that was going to purchase a quarter million dollars worth of storage area network and disaster recovery appliances for Exchange Server 2007. Instead, the company spent $70,000 and migrated to Exchange Server 2010, and got better high availability and disaster recovery than it would have otherwise.

We worked with a smaller organization of 200 people that was going to purchase a quarter million dollars worth of storage area network and disaster recovery appliances for Exchange Server 2007. Instead, the company spent $70,000 and migrated to Exchange Server 2010, and got better high availability and disaster recovery than it would have otherwise.

For companies that jumped from Exchange Server 2003 to 2010, was the migration particularly complex or cumbersome?

Morimoto: Anyone who has planned for or done a migration from Exchange Server 2003 to Exchange Server 2007 knows that it takes a good amount of time. From a planning process, the amount of time varies by organization size. But you'd typically spend a day or two planning for and creating the migration process. Administrators would also spend anywhere from one day to one week doing prototype testing to make sure that the migration works.

For smaller organizations, we've been able to do the migration from Exchange Server 2003 to 2010 on a Friday night. For larger organizations, we might migrate one site over the weekend. If the company has four to five sites, we're looking at three or four weekends. For very large environments, since you can go server by server, we would stick in a server and migrate a server when we could block it off. That might be every night or every other night; it's just a matter of how much time it takes to move the mail. It's not a complex migration.

What gotchas have popped up during these early adopter migrations?

Morimoto: We've seen technical gotchas, but what's most important is to know that you've got to take the time to plan the migration and test it in the lab. The biggest challenge I find is that a lot of organizations go straight from concept to deployment. They start moving mailboxes and don't realize how much mail they really have to move or they don't know that they have corrupted databases before they begin.

Migrating a corrupted mailbox database takes three to four times longer than moving a regular mailbox. If you have a lot of corruptions, you could be sitting there all day just trying to move the first 10 mailboxes.

The thing is, all of these things are easy to find if you perform lab testing and prototyping. When I say "prototype," I mean taking a backup of the current Exchange Server environment and testing the migration before production. If it takes us eight hours to do it in the lab, we know it's going to take about eight hours in production.

If we have any trouble migrating in the lab, we can isolate things and figure out what the problem is, then come up with a fix. So when we go into production, it's a no-brainer because we've already come up with a workaround. I can't stress the need to do prototype testing strongly enough.

It seems that large companies are good at doing this, but it might be more difficult for smaller-sized organizations. Why is this the case?

Morimoto: It's because there's so much stuff they [larger companies] have to do, there's a lot of planning for migrations in large companies. But many smaller and medium-sized companies just don't have the time, the equipment or a test lab. That's a big failure.

You couldn't buy a $5,000 piece of hardware, therefore you had a failed migration and your IT staff had to spend all weekend rolling back. Of course, labor is cheap. If you pay people on a salary basis, you might not care if they have to spend all weekend fixing problems. It's amazing, people say they have no time to do things but that's because they're always doing things the wrong way. If they did it right, they would have more time to do everything right.

How much of a learning curve do administrators face with Exchange Server 2010?

Morimoto: Exchange Server 2010 has the same administrator interface as Exchange Server 2007. So anybody who is familiar with Exchange Server 2007 will find administering and managing Exchange Server 2010 exactly the same.

For those who haven't used Exchange Server 2007, it's different. I suggest that administrators use the time in the prototype testing lab to fiddle with stuff and learn the interface. If you might have spent a day in the lab, you might as well spend three days in there. One day should focus on testing out the migration process, and a couple of days would be for doing failovers, failbacks, making sure you understand how to migrate mail, figuring out how to add and delete users, looking for lost messages -- all the tasks you might normally perform with Exchange Server.

We started this conversation talking about early adopter benefits of Exchange Server 2010. What are some benefits users can expect?

Morimoto: We hear lots of complaints about Exchange Server 2003 performance, a few of which are:

  • When I click on mail, it takes a long time to show up.
  • When I try to open someone else's calendar, it can take 20, 30 seconds, even two minutes for the person's calendar to open.
  • If I try to open 10 calendars, I might as well go get cup of coffee and come back. I get a lot of little prompts that say, 'Outlook is trying to connect to Exchange Server, please wait.'
  • I have a Web interface that is neither friendly nor intuitive.
All of these problems go away with Exchange Server 2010 because it's built on a 64-bit environment and runs faster and better than the 32-bit Exchange Server environment.

Any user who has ever had database corruption will be happy, because Microsoft has fixed a lot of those types of problems on the back end. Mac and Linux users will also jump for joy because of full-browser support. Users limited by mailbox size now have archiving. Microsoft also includes voicemail integrated into Exchange Server 2010, and it's one of the best voicemail features around.

Let us know what you think about the story; email us.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.