With every new release of Microsoft Exchange Server, you're probably familiar with all the hoopla and hullabaloo that comes out of Microsoft, telling how it's the greatest thing ever and how your messaging system—and by extension, your company—can't survive in the business world without it. But of course, you know that's not the case. Furthermore, as you investigate that new release—say, Exchange Server 2010, for example—you've probably uncovered some unanswered questions, things that don't make sense in your environment, things that make you hesitate before recommending an upheaval in your current systems, which after all are getting along just fine.
Recently I had the chance to speak with Astrid McClean, senior technical product manager on the Exchange team at Microsoft. I asked her some of the questions that I've been hearing from readers, and her answers get well beyond the hoopla. Do they clear up every hesitation for you? Dive into the interview to discover that for yourself. And if you still have questions, send me a message to let me know what they are.
Q: What is the recommended upgrade path from Exchange 2003 or Exchange 2007? And why is there no in-place upgrade option? That's a point readers have commented on that they're sort of frustrated about.
McClean: Yes, I understand that. One of the major reasons that we don't have in-place upgrade in this version is that we've actually significantly changed the mailbox database schema. It's something we don't talk about a lot, but a lot of the I/O improvements we got were from changing that database schema. And that basically means that you need to do a move mailbox to get mailboxes between versions. So that's one of the reasons that we don't have an in-place upgrade.
We know that we still do have a lot of customers running Exchange 2003, and a lot of those customers will be at a point where they need to replace their server hardware. So while they can't do an in-place upgrade, we really try to make it as easy as possible to streamline the deployment experience. And I don't know if you've seen our Exchange 2010 Deployment Assistant—we released that recently to give people some streamlined steps so that they can choose where they're upgrading from, whether it's 2003 or 2007, and you just answer a few simple questions about what features you're using, and it gives you some step-by-step instructions about how to actually do the deployment.
Q: Right, I think I saw that announced on the Exchange Team Blog.
McClean: Yes, we've kind of got a discussion of it there. And that's really designed to make sure that the deployment is as easy as possible for IT pros. So not only does it give them step-by-step instructions, it gives them the ability to have a look at those before they have to do the deployment to see what's involved. And that's really based on the experience that we've had with our early adopters as well as with our own internal deployment, so it's really got all the best practices about how to do it well and how to make it really successful.
Q: Does the assistant cover how to migrate to the cloud or to a hybrid cloud/on-premises Exchange set up? I know that's an option Microsoft has been talking about a lot with this release.
McClean: No, not at this time. Right now, the only Exchange 2010 cloud solution we're running is actually for our Live@edu program, which is for our education customers. So for the general, more commercial customers, we'll be looking at upgrading our Exchange Online to Exchange 2010 later on next year. Once that's in place, that's certainly an option for people as well.
Q: How does Exchange 2010’s built-in archiving compare to third-party archiving solutions? What was your intent for adding this feature?
McClean: The initial intent for adding that feature was really to provide our Exchange customers with a way to get all of the data from their PST files—which cause a range of headaches—back under the control of Exchange. So from a user-experience point of view, they have this one place where they can get their data. It's a familiar user experience. And from the administration side of things, they've got one set of tools that can manage their data. We know that around 80 percent of our Exchange customers don't have any archiving solution at all—their solution is typically PST files. So really, the personal archive is a way to get that data into Exchange and get it into a managed environment.
So in terms of, I guess, comparison with other archiving products, there's probably a lot of things that we don't do the same way. The personal archive in Exchange 2010 might not be suitable for companies that have really complex compliance scenarios or regulations, but for a lot of companies out there that are using PSTs, it's an ideal way to get that data back under the control of Exchange.
Q: What feedback have you heard from early adopters and your Technology Adoption Program (TAP) members about this feature?
McClean: We've had a number or our early adopters that have looked at the archiving feature and said, "This is exactly what I need." Because they want a way to get that data back in Exchange, and they want it to be as easy as possible for their users to access. I guess time will tell whether we get a large number of people that take up that option, but this is the first time that we're introducing it. And we've actually had a lot of feedback about how easy it is to use and how easy it is to manage.
Q: Do you have any sense yet of how you plan to use or develop this feature in future versions of Exchange?
McClean: It is hard to tell what it is that we're going to do, but it's certainly something that is part of our mailbox strategy, and we'll be listening to customer feedback to see what it is that customers are needing from Exchange. And if they need more functionality in that area and they're looking for it, then that's certainly an area we'll look to develop.
Q: One of the most exciting new features in Exchange 2010 is the Database Availability Group (DAG) as a means of high availability. What do Exchange administrators who have become adept at managing Exchange clustering with previous versions need to know to quickly leverage DAGs?
McClean: This is really an evolution of the continuous replication that we introduced in Exchange 2007. So we had CCR and SCR \[cluster continuous replication and standby continuous replication\]. So for those that are familiar with that way of keeping a database copy updated using log shipping, a lot of those same principles still apply. But one of the big differences now is that everything happens at a database level. The other thing we've done is we're now combining the onsite and offsite replication into a single solution. It scales up to 16 servers and that means you can configure up to 16 copies of each database. And because that failover is at the database level, it means the failover time is really reduced down to 30 seconds or less.
So the concepts people will be somewhat familiar with if they understand Exchange 2007, but from a deployment point of view, we've made it a lot easier. We’ve got this incremental deployment model now, which is quite different from what we had in previous versions of Exchange. Instead of having to first create a cluster and do all that work, now the administrator just needs to set up the Exchange mailbox database. They can then create their Database Availability Group, add servers to it, and create copies of the database when they need it. And all of that administration is done through the Exchange management tools.
We've really tried to make it as easy as possible for the administrators. The customers that we've spoken to about DAGs, as soon as they see it or they read about it, they get really excited because they say, "Hey, this is something I can do, this is something that's easy to do, and this is something that I can add as I need it into my environment." It's not something that they have to plan fully ahead of time. And in addition to that, especially for smaller customers or for customers that have smaller locations, you can have all of the Exchange roles now on the servers that are made highly available, so you can have this highly available Exchange system in just two servers. And also, the high availability is now in the Standard edition of Exchange, whereas previously it was in the Enterprise edition. We think that will be a good bonus for smaller customers as well.
Q: Yes, the ability to do incremental deployment seems like a huge selling point. What are you hearing from people about that point?
McClean: Absolutely. People are thrilled with that. In the past, if they had a mailbox server and they suddenly decided they needed to cluster it, they've had to break down the server, move all the mailboxes off, create the cluster. So the idea that Exchange can do all that work for you, and already move the server to a Database Availability Group, and it'll manage the cluster in the background, is certainly something that our customers are very exciting about because it just makes the whole process so much easier.
Q: New features in Exchange 2010 such as DAGs and the personal archives are certainly going to change the storage demands on Exchange organizations. How can Exchange administrators calculate their storage needs for an Exchange 2010 deployment?
McClean: Well, we have a calculator for them! In the past, we had something called the Exchange Storage Calculator. But we've just released an update to that that we're now calling the Exchange 2010 Mailbox Server Role Requirements Calculator. And we've changed the name of it because it's gone beyond just calculating storage. So you give it some inputs around how big your organization is and how big your mailboxes need to be and that sort of stuff, and basically the calculator will give you things like your mailbox database configuration, how many transaction logs will get generated, what the memory and CPU requirements are for your mailbox servers, what the recommended storage architecture is. And if it's a highly available configuration, it will do things like tell you how many active databases per server there are as well as, for instance, if you have a single failure, then you have this number of active databases per server, or if there's a double failure, it increases to this number of active databases per server. So, it's going to be a great tool, especially for larger environments, to calculate both storage requirements as well as the mailbox server requirements.
Q: And this tool is available as a free download?
McClean: It is indeed. There's a link to it from the EHLO blog.
Q: What are the considerations for choosing among various Exchange storage options, such as SAN or DAS? Is that also covered in the calculator?
McClean: In the calculator, you can select what type of disks you'd like to use. It does make recommendations, especially around whether you use RAID or JBOD, because there are some requirements we have around using JBOD, like having multiple copies of your databases. If you have lagged copies of your databases, we suggest you only use JBOD if you've got two lagged copies in the same site. So those kinds of decisions, the calculator will help you make. It will help give you a comparison about how many disks you need as well.
Q: The process for applying various retention policies gets easier with Exchange 2010. What are the particular aspects of this that will help save time and frustration for IT pros? It's going to be quite a big change for people who have gotten used to the managed folders method of Exchange 2007. Plus you've added the ability for end users to add their own retention policies, which could potentially complicate the management side of things.
McClean: I guess what I can talk to is how we've made those retention policies a little bit more user-friendly. One of the biggest problems that users had with the managed policies is they didn't know when an email was going to expire. You'd have to know it went in this particular folder. One of the big improvements they've made in 2010 is now you can look at the email, and it will tell you not only what policy has been applied but when it's going to expire.
Q: That's a really nice feature.
McClean: Yeah. So you're able to visually see what's going to happen. I think that particular feature alone will allay a lot of the user concern because suddenly these policies become visible to them. So for many users, they're probably not going to apply the user policies. They'll look at what the administrator has done and go, "Yup, that's nice. At least I know what's going to happen."
But for those that want a little bit more control over their email, or perhaps they have an email in a particular folder that they want to override, at least they have the ability now to override the policies. And they're still policies that are sent down from the administrators, so it's not like they're creating their own. They can apply those individual policies to a message that's particularly important to them, and even if that policy differs from the policy on the folder, it will be retained for that longer period of time. I think most users will find this a much more easy-to-use system and something that actually gives them that visual indication, and gives them a lot more control.
Q: Can admins choose not to allow end-users policies?
McClean: Yes, if they don't publish policies for the users to use, then users can't set any.
Q: Can end-user policies trump admin policies?
McClean: You can override a policy on an individual email by applying one of the policies. But remember that the policies that you're applying are the ones that the administrator sent down. So the user can't decide, for example, to keep an email for 100 years if that isn't a policy that the administrator has sent down for the user to use. It's really about giving the user a level of control, but the level of control they get is still set by the administrator because they can only apply the policies that have been sent down by the administrator.
Q: OK, now it's starting to come clear. So end users can't just create their own policies?
McClean: No, they can only apply policies sent down from the administrator. So it's giving them that level of control without just giving them carte blanche to do anything they like.
Q: Although Role-Based Access Control (RBAC) looks like a powerful permissions model, some of our readers are worried that it will be complicated to use. What do they need to know to get up and running quickly? What are the benefits of RBAC for administrators?
McClean: The feedback that we've had on this one is once people get the general concept of how it works, they're very excited by it because suddenly they have a lot more control and it's a lot easier to manage. One of the things we changed from the beta to the final release is the way that we manage the RBAC roles. And it was precisely changed to make it easier for IT admins. So we introduced the concept of the management group. There are eleven of these that are built in, and these cover the main delegation scenarios that we think a lot of organization will use.
A role group will have a number of roles associated with it. It's things like discovery management or UM management or server management or Help desk. These are really common scenarios. In part of the Exchange Control Panel, we've given a really easy-to-use interface for the administrator to go in and assign a user or a group to one of these role groups, and as soon as they're assigned, they have those permissions. So for the vast majority of our customers, that's all they'll ever have to do.
But if you want to go in more granularly than that, we've also got those role groups that are made up of around 65 built-in roles. They already have tasks assigned to them, and you can then say, "I want to delegate particular roles," for example. And again, you don't have to create these complex roles or anything—they're already there for you. And with 65 of them, that's somewhat granular, and that will meet kind of that next level down if you want to do some delegation. And if you've got a really complex delegation scenario—well, you can do anything you like, really, and do delegation.
But we think that for the majority of our customers, they'll be able to use the built in role groups or the next level down for roles, and very easily give the right level people the right tasks to do their job. The feedback we've had from customers once they see that interface and see those role groups, they say, "Hang on, that meets most of my requirements. This is easy."
Q: Are there additional benefits for end users from this system?
McClean: Absolutely. One of the things we've done is this whole end user self-service idea. So from OWA, when you go to the Options button, you go to the Exchange Control Panel. And that has grown from not only the OWA options but also this self-service portal. And if you've been give permissions, it means that you're able to do things like join a distribution group or track a message. Or if you're a compliance officer or discovery-management person, that's the same interface you'd use to do your multi-mailbox search.
The idea behind that is that it empowers users to do the things that they're able to do. The administrators know that permissions have been delegated in a really controlled fashion. And it means that the users can do these things without continually calling the Help desk or calling the administrator, which means the users get less frustrated because they can just get on and do their job. The administrators have more time to do what they need to do rather than answer all these tasks that they get asked to do repeatedly.
Q: With Exchange 2007, there was initially a lot of resistance to Windows PowerShell and the idea of Exchange management through the command-line or scripting. Do you have a sense of what users are saying now? Have they become accustomed to PowerShell in Exchange? How does remote PowerShell in Exchange 2010 affect this picture?
McClean: What we're seeing now is the use of PowerShell both across Exchange and across other products is growing, so people are certainly becoming more comfortable with the concept of managing a server using PowerShell. But we've tried to put as many of the common tasks into the GUI as possible. So whether it's the Exchange Management Console or whether it's the Exchange Control Panel, the majority of the work can be done with some sort of GUI management tool.
But because all of those tools use remote PowerShell on the back end, we've also allowed you to do things in the Exchange Management Console where you can see what command is going to run so that if you do want to use that command later as part of a script, or you want to understand what's happening, you have the power to do that. We've made some enhancements to the Exchange Management Console this time around to make that easier. In fact, there's a PowerShell log that will log everything that happens in Exchange Management Console so you can actually see what's going on. We've tried to make it easier for people to make that link between the two if they need to go to PowerShell to do anything that they've been doing through the GUI tools.
From a remote PowerShell point of view, two things make that very powerful. You're able to manage, for example, additional Exchange forests through the Exchange Management Console now. And that's made possible because the connection is made through remote PowerShell. So you can make this remote connection and manage more than one forest, for example, through the Exchange Management Console. The other thing that it's allowed us to do is it sets the basis for the GUI tools we're using with RBAC and then only showing you the features in the tools that you actually have access to. And because remote PowerShell has this concept of restricted run spaces, it only gives you access to the things you have access to through RBAC.
So it's given the administrators an easier-to-use tool when they delegate things The other thing for remote PowerShell—it also enables customers that don't have a 64-bit OS to install the management tools. They're actually able to run remote PowerShell on a 32-bit OS and still connect to the Exchange server and do scripting through there. So it's given us quite a powerful platform to work from.
Q: The Outlook Web App (OWA) improvements in Exchange 2010 seem to make it a true rival for the Outlook desktop client. Do you anticipate this situation affecting upgrades to Outlook 2010, which isn't available yet?
McClean: I don't think it will stop people upgrading. But it gives organizations more choice. So what we're finding is a number of organizations where they may not have given their users email access at all because they don't all have a PC or they're working on shifts and have to share PCs—it now gives them a far greater option to give their people a browser-based tool to connect to. So it's really about making sure that organizations have a choice about which tool they want to use, and in making that choice they're not losing functionality, which is why you'll see a lot of the functionality in OWA is reflected in Outlook 2010. So it's about making sure that we give as much parity across all of our clients as possible.
Q: What features are available in OWA 2010 and, eventually, in Outlook 2010 that you won't get with Outlook 2007?
McClean: I don't know if I have a complete list, but the major ones would be conversation view, the new conversation view that's actually driven from Exchange. MailTips is something that's only available in those two. The personal archives is only accessible in OWA or Outlook 2010. The calendar sharing options where you can share privacy information with other organizations. They're probably the major ones.
Q: But if you upgrade to Exchange 2010, you can use all of these in OWA, even if you haven't upgraded Outlook?
McClean: Absolutely.
Q: We've covered a lot of ground and I'm sure you've answered some questions our readers still had about Exchange 2010. Do you have anything to add?
McClean: We're really excited about this release. I've just come back from TechEd in Europe, where we did our launch in Berlin, and the buzz from the community and the people that stormed our booth was really quite infectious. We had a lot of excited people. A lot of our sessions, we had to turn people away because there was just so much interest in them. There's a really high level of buzz about this and it's great to see because we've put a lot of work into this release. We know there are a lot of good features in there, and it's really good to see the community reaction to those features by getting this feedback. There are a lot of excited people out there.
Q: One of the things we've encountered in the past when we start writing about the newest releases is that many IT pros in our audience, for whatever reason, simply aren't ready for upgrading yet. Did you encounter any of that sort of sentiment as well?
McClean: One of the things that we have heard is that there's a lot of our Exchange 2003 customers, and they say to us, "Well we were looking at Exchange 2007, but now I've looked at what Exchange 2010 has got and we're going straight there." And that's something that we hear over and over again from 2003 customers. And even some 2007 customers, although there's no in-place upgrade, because we have the online move mailbox feature, which means that they can move mailboxes across to the new infrastructure without impacting their users, that certainly softens the blow in terms of user impact, which in the end is something that's most important to organization. That's a feature that people are particularly excited about in terms of making it a very smooth deployment process.
Related Reading:
