With the release of Exchange Server 2010, organizations that are on Exchange 2007 are weighing when they are going to shift to Exchange 2010 to take advantage of the new features of capabilities, and organizations who are on earlier versions (like Exchange 2003 or even Exchange 2000) are considering their options to leapfrog over Exchange 2007 and go straight to Exchange 2010.
As with any migration process, there are things that work, and there are things that don’t work. This article will cover the high level good, the bad, and the ugly with upcoming blog posts where I’ll provide specific migration steps, tips, tricks, and best practices. For now, this post is to give you the overall view of the migration.
The Good
Exchange 2010 from an overall design perspective is really nothing more than a service pack type revision of Exchange Server 2007. Server roles like Client Access, Hub Transport, Mailbox, and Edge server roles are the same between Exchange 2007 and Exchange 2010
With similar server roles, if you have already deployed Exchange 2007, you would just build out Exchange 2010 server roles similar to what you have today. So if you have 2 CAS servers today in Exchange 2007, you’d build out 2 CAS servers for Exchange 2010. If you have combined your CAS and Hub Transport (HT) roles into a single server today in Exchange 2007, you’d likely combine your CAS/HT server roles into a single server in Exchange 2010. If you virtualized your CAS, HT, and Edge servers today in Exchange 2007, you’d virtualize those server roles in Exchange 2010
For organizations that have planned their migration from Exchange 2003 to Exchange 2007 but haven’t completed the migration, you can for the most part just search/replace Exchange 2007 to Exchange 2010 in your architecture and design documentation and deploy Exchange 2010 instead of Exchange 2007 (note: you will make changes to the way the Mailbox role is handled as Exchange 2010 no longer supports Single Copy Clusters or Cluster Continuous Replication but instead uses Database Availability Groups, however for the most part, the design of Exchange 2010 is similar to that of Exchange 2007 with some (pretty significant) improvements)
Because Exchange 2010 now writes data to the EDB databases sequentially (instead of as random disk writes), Exchange 2010 is SIGNIFICANTLY more efficient at disk read/write IO. Where we used to recommend organizations get extremely high IOPS supported SAN storage, with Exchange 2010, we have deployed the same configurations on iSCSI (instead of Fibre Channel) or even local storage SATA drives (this has resulted in significant savings in the cost of storage for organizations migrating to Exchange 2010)
If you’re familiar with the Exchange 2007 Management Console, the management console for Exchange 2010 is identical, no relearning the administrative interface
If your client systems are running Outlook 2003 or Outlook 2007, you can effectively make the change from Exchange 2003 or Exchange 2007 to Exchange 2010 without the users ever knowing you have upgraded the backend servers because if migrated properly, the client connections automatically connect to Exchange 2010 without the user ever knowing the backend was upgraded
I noted in an earlier posting on the top features and functions of Exchange 2010, but in a snapshot, the big movers are the database availability groups (DAGs) that effectively does away with the need for 3rd party high availability and disaster recovery solutions and drastically lowers the cost of Exchange TCO. And the archiving along with the support for non-Windows clients has been a big draw for organizations to jump on their migration to Exchange 2010.
The Bad
It was a toss up whether I put this in the Bad or the Ugly column, you decide. With Exchange 2010, when you migrate from Exchange 2003 or Exchange 2007 you must maintain your old Exchange 2003/2007 environment until you are completely migrated to Exchange 2010. In a migration from Exchange 2003 to Exchange 2007, the minute you put in a CAS frontend to Exchange 2007 for Outlook Web Access, that CAS server would also host Outlook Web Access for the Exchange 2003 mailboxes, so you could just remove the Exchange 2003 Frontend server(s) once Exchange 2007 CAS servers were in place. Or an Exchange 2007 Hub Transport server would route messages for both Exchange 2007 as well as Exchange 2003 bridgehead servers. But with Exchange 2010, the Exchange 2010 CAS server will only frontend an Outlook Web App web session for a mailbox on Exchange 2010, and for users with their mailbox still on Exchange 2003 or 2007, you must have an Exchange 2003 FE or 2007 CAS server for those users. Likewise, an Exchange 2010 Hub Transport will only route messagesfor Exchange 2010 backend mailbox users, that users on Exchange 2003 still need an Exchange 2003 bridgehead server, and users on Exchange 2007 still need an Exchange 2007 Hub Transport server in parallel to the Exchange 2010 environment for messages to route. Microsoft did not build in backwards compatibility on server roles because to do so would have meant that the Exchange 2010 server roles would have to be “dumbed down” to support legacy server roles forever, and if you only do the migration once, just get migrated completely to Exchange 2010 and be done with. What we found is that since we can virtualize the CAS/2010 and HT/2010 roles, we could build out the parallel environment pretty easily. Most E2007 CAS/HT roles today are virtualized, so it hasn’t been like most organizations have dedicated hardware these days. And Exchange 2003 servers typically can’t be reused for Exchange 2007 or Exchange 2010 due to the age and support for 64-bit, so orgs migrating from Exchange 2003 to Exchange 2010 have had to buy new hardware or virtualize anyway. Your call if this is Bad or really Ugly. When we did our first migration to Exchange 2010 a year+ before RTM under the early adopter program we thought it would be really ugly, however Microsoft built-in proxying to the CAS/2010 server so that you point all users to hit the CAS/2010 server for things like Outlook Web Access and they get redirected to the CAS/2007 or FE/2003 if their mailbox hasn’t been migrated yet
For some, this might be bad although most orgs it’s been a non-issue. Exchange 2010 requires that your Active Directory be on 2003 Native mode. Most orgs have gone to 2003 Native already, although amazing how many organizations still have AD/2000 or never flipped the switch to get out of 2003 Mixed mode. Come on folks, I hardly doubt there are NT4 “domain controllers” still in your environment to be running in Mixed mode. You can run NT4 member servers in a Native Mode environment so if you happen to have a really old legacy application, you can still run NT4 member servers in 2003 Native. So this might be a pre-req to get your AD to at least 2003 Native mode before you deploy Exchange 2010. In the scheme of things, a migration to AD/2003 Native mode is typically a Friday night cutover type of thing, so hopefully this isn’t too bad of a requirement.
By the way, I’m always asked if migrating to AD/2008 or AD/2008R2 is better for Exchange 2010, the answer is “no”. Exchange 2010 doesn’t require AD/2008 or AD/2008R2 features, and while there are some really great things in AD/2008 (like fine grain passwords where you can set password policies “per group” instead of having the same password policy for your entire domain) or AD/2008R2 supports AES256 encryption. So these are more like Windows things, not particularly Exchange things that you get when you go beyond AD/2003 Native mode for your migration to Exchange 2010
I’m going to put this in the bad column however for a product that is “just” releasing to the public, you’d think that 3rd party vendor support or basic functionality support would be in the ugly column but it isn’t. For the release of Exchange 2010, 3rd party vendors like RIM Blackberry, Symantec, and the like are releasing updates to their products almost immediately after product general availability. The Exchange Team has learned from the past where they’ve released products and it was a year or two before mainstream vendors had support for the product, so with Exchange 2010, they got their 3rd party vendors very involved in the beta so that their products were tested and working by the time the product released.
The Ugly
Okay, had to come up with something in the “ugly” column here. What I’d identify as something that has been an issue for some organizations is the lack of support of a direct migration from anything prior to Exchange 2003, so effectively if you are still running Exchange 2000, Microsoft does not have a migration wizard to get you to Exchange 2010. There are many ways we’ve accomplished the migrations from Exchange 2000 to Exchange 2010 including using 3rd party tools like the Quest Exchange Migration Wizard (EMW) product, or we’ve had organizations migrate from Exchange 2000 to Exchange 2007, and then just add Exchange 2010 servers to the Exchange 2007 environment and move mailboxes over (if you don’t plan on to stay Exchange 2007, you don’t have to build out a hugely robust environment, we’ve done it completely on virtual servers for Exchange 2007 as a pass thru up to Exchange 2010). So it’s not pretty if you have Exchange 2000, however you aren’t dead in the water either. Just as a side note, if you haven’t noticed, Microsoft has been supporting migrations from the last 2 version to the new release but nothing prior. So Exchange 2010 supports migrations from Exchange 2007 and 2003. Windows 7 supports migrations from Windows Vista and XP (but not from Windows 2000), etc. So here forward, you need to make sure you are not more than 1 version behind.
In upcoming posts, I’ll cover specific best practices on migrating from Exchange 2003 to Exchange 2010, and for migration from Exchange 2007 to Exchange 2010. I’ll provide some step by step guidance as well as migration tips and tricks based on a couple years of early adopter experience with Exchange 2010. Stayed tuned for more…