It's been roughly six months since Microsoft Exchange Server 2010 was released into the wild of the business world—time enough, certainly, for IT departments to get familiar with the new mail server and what it has to offer and determine whether to push their organizations toward an upgrade. Naturally, Microsoft hopes you'll move to the latest version, and the company has taken great steps to help you make the transition as easy as possible. I recently spoke with Rajesh Jha, corporate vice president for Microsoft Exchange, about what Microsoft is doing to prepare companies and about some of the tricky points of Exchange 2010's new features that IT pros should be prepared for.

(Editor's Note: This interview took place before Microsoft announced any of the features of Exchange 2010 SP1.)

B. K. Winstead: Let's start by looking at what Microsoft is doing to help customers make the transition. For instance, you have the Exchange Server Deployment Assistant on the website, which was recently upgraded to include additional deployment scenarios that weren't available when Exchange 2010 launched. Are you planning to continue adding other scenarios, such as migrating to cloud-based Exchange or using virtualization?

Rajesh Jha: We've gotten very positive feedback on the Deployment Assistant from our customers. What the wizard does is, instead of having customers go and find all the relevant stuff that applies to their configuration, it gives them a higher-level wizard to navigate their specific circumstances and find the white papers or documentation that's relevant for their situation. In fact, the single biggest thing we hear is, "Wow, this is so personalized for my situation; thank you very much for doing that."

But at the same time, we don't have all the flavors in the deployment wizard today. The documentation exists for all of these \\[scenarios\\], so we will continue to add more steps in the wizard as we get more feedback. As people say, "Hey, I wish virtualization was called out," then we will add that. We'll add online. We think this is a very scalable way for us to guide our customers. It's scalable in a personalized way. It's absolutely something we'll continue to invest in.

The Exchange node on TechNet \\[has\\] a whole section on how best to migrate to Exchange 2010. The wizard is just a higher-level overlay on the set of content that we have there. The other thing we've done this time is—Exchange used to always provide guidance in the Storage Calculator—we've enhanced that significantly. \\[It's now called the Exchange 2010 Mailbox Server Role Requirements Calculator.\\] Again, this is very customizable—depending upon the storage type, how many copies they want to use, the kind of disaster-recovery capabilities they want to build in. We provide guidance to customers in terms of how to size their disks, how to size their CPUs, and memory usage. So we've built not only the deployment wizard, which is more like a step-by-step process, but also sizing guidance that is personalizable for the different configurations that our customers might need.

Winstead: Do you have any advice for organizations planning to deploy Exchange 2010 in conjunction with virtualization?

Jha: Yes, on our website we have guidance, and we continue to refresh the guidance. We support virtualization. For some customers, this does make sense, to virtualize. For many of our customers, the email infrastructure is so heavily loaded, and it's so heavily used, that virtualization may not make sense. We've got guidance that walks people through what to virtualize and the sizing guidance if you virtualize on a single box the Mailbox role, the CAS role, the Hub role—that kind of guidance. So the calculator actually walks you through the virtualization options as well.

Winstead: Virtualization isn't covered currently in the Exchange Server Deployment Assistant. Do you think it's something you'll add at some point?

Jha: I think it totally makes sense for us to add it at some point. I know the team is going through the most popular requests. In the deployment wizard, we've got a bunch of mainstream deployment options, and we are receiving feedback saying, "Hey, I would like to see this one covered as well." We are working through the feedback methodically, taking the most requested stuff and adding that.

Winstead: One of Microsoft's key talking points at the time Exchange 2010 was released was how it would save organizations money. Is that message sticking with people? Or are budgets still too tight for most companies to be able to make such a major switch at this point?

Jha: I think the Exchange 2010 story of cost savings is very strong, and it's still resonating with customers. Not all the saving mechanisms apply to all customers, but there is so much in it that something applies to almost any customer. There are customers that have been able to increase their storage size significantly and provide much bigger mailboxes to their end users while reducing their costs byte by byte based on what they had on Exchange 2003 by just moving to cheaper storage options in Exchange 2010. There are customers that have been able to get rid of their parallel investment in backup or disaster recovery because in Exchange 2010 we have the database availability group where customers get to choose how many copies of the data that they have. We've unified the notion of backup and availability and disaster recovery into one architecture. So there are customers that have had cost savings by just getting rid of their third-party backup systems and using the database availability groups for backups.

Then there are customers that had a parallel system for voicemail, and with Exchange 2010 we allow, on the same Exchange servers, for you to be able to offer unified messaging and voicemail. That's another cost-savings option. Around 80 percent of customers don't have archiving today, but the vast majority of them see some need to get archiving into place. Again, with Exchange 2010 the same email infrastructure allows you to do archiving, retention, discovery. And finally, for our smallest customers, the promise of either being on-premises or in the cloud, that's another cost savings. They can just move to the cloud and they'll get the exact same functionality of Exchange 2010 in the cloud as they do on-premises.

From an operation-cost perspective, we made investments in role-based access control. It's a low-level authorization module that we built into Exchange on top of which an IT pro can delegate certain tasks—such as the discovery task or Help desk task or distribution list management or message tracking—either to end users or to specialized roles in their organization. So that reduces operating costs. So actually the story for cost-savings is resonating with our customers, and if you take a look at the body of case studies we have on Exchange 2010, it's incredible just the wide variety of cost savings our customers have been able to realize.

Winstead: You mentioned the ability to use database availability groups (DAGs) to eliminate third-party backup solutions. I suspect there will be some organizations that will resist this idea or be afraid to give up their backups. Do you see a particular size or type of organization that will be most willing to rely on DAGs for backups?

Jha: You raise a really interesting observation, which is the notions of high availability, backup, archiving, compliance—some customers will combine these concepts in one implementation. So there are some customers for whom their backup is also their archive is also their compliance, or the store they would go to for retention, and so on. But for many customers, they do tend to be discrete concepts and discrete workflows. And so the database availability group doesn't mandate that you have to think about all four of these concepts implemented on top of the database availability group. But you could use this for all four of these.

So who would take advantage of the backup capabilities that have been built into the database availability group? We've actually seen customers of all sizes. Here at Microsoft, we run our backup exclusively on database availability groups. The 200,000 mailboxes at Microsoft are actually implemented on that mechanism. The service that we're running for 20 million educational customers runs on that infrastructure. We have smaller customers—there are case studies, I forget the exact number of seats but it's not a lot—that have actually gone with this mechanism for their backup needs. But there will be customers that will say, "No, I'll use database availability groups for high availability and disaster recovery, but I want to stick to my existing backup process." And that's fine, too.

Winstead: You mentioned the archiving feature in Exchange 2010—that's something that you're offering for the first time with this release. I know people I've spoken with have real concerns that the archive is stored on the same server as the primary database, which isn't the traditional way you think about an archive. At this point, do you have any idea of how you'll be developing the archiving feature either in service packs or future releases of Exchange?

Jha: Let me start by talking about what the archive feature in Exchange 2010 is. It allows the IT pro to solve the PST problem. Most organizations today have a bunch of PSTs that aren't under management by the IT pro. And it's not that the end user has a great experience. I mean, if you have a PST on your primary desktop, you can't get to it or do a search on it when you're on your mobile device or on a browser or a different desktop. So by bringing all these PSTs in, a couple of things happen. The IT pro is now able to manage these, and do discovery against these. And the end user gets anywhere access, so now you can do a search across your PSTs—what used to be your PST is now your online archive, and it's available to you from anywhere.

So that's one thing. And we have capabilities for the IT pro to put legal holds, do discovery, without having a separate infrastructure for archiving. Many of our customers need that. Customers that don't have archiving today are able to get that on their messaging infrastructure. We've received feedback that's saying they aren't comfortable with the archive and the primary mailbox being in the same database. And it's feedback we've heard loud and clear, and we're working through our plans on how best to address it. I don't have anything to share at this time, but yes, we do have the feedback. \\[Editor's note: The ability to provision the archive on separate storage from the primary mailbox database has been announced as a feature of Exchange 2010 SP1.\\]

The one thing I would offer up, though, is it's not something that actually increases their costs, the way it's implemented today. If anything, I think it offers an opportunity to reduce costs. If you think about the costs of storage, what you end up paying for is the speed of the disks. You don't end up paying that much for the size of the disk. The disks are getting bigger and bigger and cheaper and cheaper. What's not getting cheaper is how fast these disks go. If you think about how storage and archives are accessed by the end user, it's sporadic access. It's not something you go back to. The half-life of email isn't very long.

So if you co-locate email that's accessed very, very rapidly with lots of storage that isn't accessed very often—in other words, you co-locate hot storage and cold storage—then you're taking advantage of the laws of physics, where the disks are getting bigger. The disks aren't getting faster, but you don't need more speed for the archive to be co-located because it's not accessed that often. If you keep the archive and the primary mailbox in two different databases, you're going to end up paying for the spindles separately anyway.

For some set of customers, the opportunity to co-locate hot storage and cold storage is exciting because it offers them over the long run substantially reduced storage costs. But some of them do want the archive in a different database from the primary database, and that's some feedback that we've taken and we're working through how best to offer up that choice.

Winstead: One of the things we heard initially from our readers was a frustration about the lack of an in-place upgrade option to Exchange 2010. Are you still encountering frustration from existing Exchange users about the lack of in-place upgrades?

Jha: You know, the majority of our installed base is still on Exchange 2003. For many of our Exchange 2003 customers, \\[they've reached\\] the end of the lifecycle of their hardware and their software—it's at a logical conclusion. So at this point, they have the opportunity to take advantage of all the new hardware, and the new flexibility built into Exchange 2010. So I understand an upgrade is really an option that many of our customers would like to see, but for the Exchange 2003 customer base, what we've heard is it's really less of an issue because their hardware is already at end-of-life.

The other reason we didn't do an in-place upgrade was we spent a lot of energy in making I/O and performance improvements. We did work on the schema of the Store—very significant work. Over two releases of the product, we've made about 90 percent improvement in the I/O profile use. This allows the customer to run on hardware that goes from just JBOD to DAT storage. So given the big changes in schema, we think we've actually allowed them to reduce their costs in moving from Exchange 2003 to 2010 with many more storage options. And one of the exciting things we've done in Exchange 2010 for our smaller customers—they can actually, with two severs, get full redundancy. They can run all the roles on a given server.

Winstead: What are some things organizations can do to get ready ahead of time to make a transition to Exchange 2010, whether they're currently on Exchange 2007 or Exchange 2003?

Jha: First and foremost is to make sure to take advantage of our sizing guidance as built out in the calculator. As you know, email is mission critical. Our customers expect this to be available all the time and have a high reliability. And a lot of that comes from making sure that the architecture that they build out for their messaging infrastructure has got the right sizing built into it. And that's why we spent a lot of energy on the storage calculator—how many mailboxes you'd use based on the amount of traffic you expect, how much memory, how you want to manage the data, disaster recovery, backup. I feel very good about the quality of the tools we have—not just the deployment wizard but the sizing calculator and other guidance that we have. And so that, I think, would be the most important thing to get done.

The good news, though, is they're going to find Exchange 2010 very well received by their end users. They get a great experience on any browser. The vast majority of the smartphones in our industry support Exchange ActiveSync so you get great conversation view on smartphones. You get that in the browser. You get voicemail transcription working on your phone or in the browser and of course in Outlook. And what's more exciting, I think, to end users is the ability to get much, much larger mailboxes made available to them, and for the IT pro to be able to offer this at no increased cost and in some cases actually at reduced cost even against a much smaller mailbox than on Exchange 2003.

Winstead: For people currently on a different mail platform altogether, what should they think about when considering a move to Exchange 2010?

Jha: I think for customers of all sizes, I would say they should definitely take a look at our cloud option with Exchange Online. Most of our customers today actually have been folks that have moved from either Lotus Notes or Novell GroupWise. It's a very exciting option to many customers because now they don't have to build a lot of expertise running Exchange on-prem—they can let Microsoft do that and keep their service ever-green with the latest version of Exchange available to them. Whether they run Exchange today or they don't, that's one of the decisions they should walk through—where do they fall between wanting more control versus delegating more to Microsoft to run in the cloud?

There will be customers that will choose to be kind of in the middle—they may move a set of users to the cloud and keep a set of users on-premises. They'll have free/busy inter-op between the two, between the cloud and on-premises. They will be able to move mailboxes back and forth, the same manageability tools, the same end-user features. So I think that's a very important consideration in the design of their infrastructure: Cloud or not? If cloud, is it everybody in the cloud or is it some set of folks in the cloud? If it's going to be on-premises, let's make sure we go through the guidance and the sizing and plan the infrastructure and then use the deployment wizard to go a step at a time to actually deploy it.

Winstead: Exchange 2010 isn't yet available through Microsoft Online Services, but should be soon. Talk about the possibilities that open up with the hosted option.

Jha: It’s going to show up in our Exchange Online service, and that's the nice thing about the online service, that our customers will get automatically upgraded by us, Microsoft, right? They sign up for Exchange Online Service, it's a service, and Exchange 2010 will show up for them. Our customers in Exchange Online get an option to opt out if they don't want to have the transition happen. They get to opt out for a year, I think. But most of them actually would like to see the latest thing available as soon as it is, and we'll do it for them. And when Exchange 2010's available to Exchange Online, all the power of the single management tool, hybrid deployment, inter-op of free/busy, online mailbox moves—all of these open up for our customers.

And so it's a very flexible option for many of them. And it's a very easy option because the same management tools will continue to work and the same user experience will continue to apply. So you're not locked into our cloud. You can always come back to your on-premises. We felt our promise of choice and flexibility is a very strong one and look to make that available to all Exchange Online customers.

Winstead: Some people I’ve spoken to in the industry seemed to reject the hybrid option, thinking it would be too complicated to implement and manage.

Jha: I really think it depends upon the specific organization. For some organizations, it may not be worth having a hybrid. They may want to say, you know, we want to have one Help desk control flow to deal with, whether it's on-premises or fully in the cloud. And that's OK. That's what I feel is the Exchange 2010 choice of flexibility for our customers. For some of them, it may be all in the cloud, some of them all on-prem.

I think some of our larger organizations that want to move into the cloud will never be completely in the cloud. They'll always be buying companies that may not start out in the cloud, for instance. And even if they decide to go in the cloud, no large customer is going to be able to go to the cloud on a single day. It's going to be a process that's going to work out over months. And during those months, you’ll want inter-op, you’ll want consistent manageability.

But I do think there will be some large customers for whom hybrid will be the way it's going to be. Even if they decide to move their entire messaging infrastructure in the cloud, they may choose to have their collaboration on-prem, or their directory will probably be on-prem. So some level of hybrid is true for most large organizations, whether it's in transition phase, whether it's a different workload, whether it's a directory. Some of them actually have structured workers or branch offices in the cloud but keep their corporate office on-prem. I think we'll see all kinds. Our customers don't come in one size and we don't want to be prescriptive in how they should run. They know what their needs are best, and we want to support them in whichever configuration they want to run.

Winstead: And if you set up a hybrid configuration, is it still manageable through one management console?

Jha: Yes, that's the cool thing. If an IT pro decides, "I want to bring this person back in house," it's the same management console, and you bring the user—it's an online move. You don't even have to recreate the Outlook offline cache—you just move the user, and they're ready to go.

Winstead: I think that message could really allay a lot of fears.

Jha: I completely agree with you! I don't think it's a good story to tell our IT pros, “Hey, you've got a different set of tools to manage the cloud, a different set of tools to manage the on-prem.” We want to give them consistent end-user experience, consistent IT experience.

Winstead: What are some of the big changes in Exchange 2010 for admins already familiar with the Exchange 2007 version?

Jha: One of the biggest changes that we made is in the Client Access role in Exchange 2010. In the past, Outlook would go directly against the Mailbox role whereas Outlook Web App and mobile \\[connections\\] would go through the Client Access role. So one of the nice things we've done in Exchange 2010 is that we have Outlook, Outlook Web App, and the mobile access—all the client access—actually goes through the Client Access role now.

This does a couple of really interesting things. One is it allows us to provide a much more consistent experience across all of these devices or all of these different clients in terms of business logic. For instance, calendaring consists of lots of business rules; so what should happen with calendaring \\[on each of these different clients\\]? Now we've got that centralized all in one place. You get a consistent experience no matter what device you're on.

And the second thing is our high-availability story. This was enabled with this architecture because the Outlook line now virtually binds to a mailbox and the Client Access role can abstract away which copy of the database you are actually binding to without having to restart Outlook. So, it has become a more important role than in Exchange 2007. If you take a look at our deployment wizard, it's heavily weighted toward walking our Exchange 2003 customers and Exchange 2007 customers over how to manage the rollout of Client Access in their organization—it's a step-by-step process.

Winstead: Exchange Server is clearly the leading mail and collaboration server in the market today. As you move to a stronger online presence with Exchange Online and the Microsoft Business Productivity Online Standard Suite (BPOS), will you take specific steps to compete with Google and Google's attempts to win customers away from Exchange and Microsoft and into the Google Apps universe?

Jha: I feel that the cloud opens new opportunities for Exchange 2010. If you think about Exchange market share, we are the leader in enterprise messaging. And in the small business space, I think with Exchange Online offering the full functionality of Exchange 2010—the best Outlook experience, and consistent, seamless experience whether you're in Outlook, the browser—any browser—any mobile phone—that's going to win out, and we will have the opportunity for our customers to actually be purely in the cloud hosted by us. It's a growth opportunity for Exchange.

We are very excited about moving to the cloud. There's some speculation that we are somehow defensive about the cloud—far from it! We are very excited about what the cloud offers. Firstly, for our large customers, they get the power of choice—software and service. And for our smaller customers, they might say, "Wow, I can get our entire IT infrastructure but get all the richness of Exchange, hosted by Microsoft and keep it ever-green and fresh." I think we get an opportunity to add share in the small and medium businesses.

Winstead: Microsoft has so many new releases out or coming out, starting back in the fall with Windows 7 and Exchange 2010, and now we've got SharePoint 2010 and Office 2010 coming soon, among other releases. IT departments will need to look carefully at what they need before jumping into any of these purchases. What will make Exchange 2010 stand out from this group?

Jha: Messaging is a key workflow. I think it's a recognition of how important communication and collaboration is to our customers in terms of the value that their businesses are able to drive. That's number one: The business value we're able to offer with Exchange 2010 is very strong.

At the same time, they actually get to save money. If you take a look at the Forrester study \\["The Total Economic Impact of Microsoft Exchange 2010"\\], it just reiterates what we've seen with all our case studies so far: Our customers will be able to save money by moving to Exchange 2010. You've got a mission-critical infrastructure. Your user needs continue to grow. You can add business value. And we are confident that we will save our IT pros money by making this change to 2010. And then the truth of the matter is a large installed base of Exchange customers today are on Exchange 2003. That product and their hardware is at end-of-life. Exchange 2010 is a great option for them.