Last week, I had the good fortune to be in Dallas to teach a class of bright, experienced sales and support engineers who work for a major software firm. They had lots of good questions about Exchange Server 2007, how it would affect their company's products, and what they needed to know to help prepare their customers for making the transition.
During the class, an interesting discussion started: Do you need more servers for Exchange 2007 than for Exchange Server 2003? On its face, this question would seem simple. However, the role and capability changes in Exchange 2007 mean that it's not actually simple at all.
Let's take the simplest case: migrating a single Exchange 2003 server to Exchange 2007. You can do a one-to-one replacement of that server with an Exchange 2007 server, and—poof!—you're done. You'll need to install the Hub Transport, Mailbox, and Client Access server roles on your single server (as well as the Unified Messaging—UM—role, if you want to use it). This type of installation is well supported and, in my experience, has worked well during the beta period. In this case, you don't need more servers than you would for Exchange 2003.
The next case is a more complex migration involving one or more front-end servers talking to one or more back-end mailbox servers. Just like the single-server case, this scenario allows for one-to-one replacement. Your front-end servers would be replaced by one or more Client Access servers, and the mailbox servers would be replaced by servers with the Mailbox role. However, because Exchange 2007 scales significantly better on the same hardware than Exchange 2003 does, you might be able to reduce the number of servers you use. HP's initial test data shows a large reduction in the I/O requirements for hardware that moves from Exchange 2003 to Exchange 2007, with further reductions in I/O operations per second (IOPS) if you move from 4GB to 8GB of memory.
Probably the most complex migration involves clustering. In Exchange 2003, you can have multiple-node clusters that handle the mailbox role; front-end servers are supposed to be made redundant through Network Load Balancing (NLB). In Exchange 2007, only the Mailbox server role can be clustered. Microsoft recommends using other technologies (including NLB) for the Client Access, UM, Edge Transport, and Hub Transport roles. If you can't cluster these roles on an Exchange 2007 system, how many servers do you need to replicate a two-node Exchange 2003 cluster?
The answer is what you might expect: You'd need two servers to replace the clustered mailbox server, plus an additional server for the Client Access and Hub Transport roles. If you wanted to add redundancy for the Client Access and Hub Transport roles, you'd need an additional server. So, to duplicate the functionality of the two-node Exchange 2003 cluster, you would indeed need more servers with Exchange 2007 (which, of course, means you'd need more Windows and Exchange licenses).
However, there are three mitigating factors to the cluster scenario. First, most Exchange administrators won't be affected because they're not currently using Exchange 2003 in clusters. Second, the local and clustered continuous replication (CCR) features in Exchange 2007 might counteract your need to use a conventional cluster (which Exchange 2007 calls a single copy cluster). Finally, clustering improvements in Exchange 2007 mean that you might not need the expensive shared storage required for Exchange 2003 clusters; therefore, your overall cost of upgrading a cluster might be lower than it would have been to deploy originally. This won't be true in all cases, but I suspect that organizations that bought SANs to use solely with their clusters might find some surprising cost benefits from ditching shared storage and using CCR instead.
Now, to a completely different subject: We've finalized the sessions and speakers for the spring 2007 Exchange Connections show. One new feature I'm really excited about is a track for vendor presentations. We're offering Exchange-related ISVs a chance to present deeply technical sessions to attendees—with no marketing fluff! We'll also have panel discussions featuring multiple vendors in a given topic area. If your company is interested in presenting, please send a session proposal to [email protected]. If you're interested in hearing from a particular vendor or want to know more about a particular technology, drop me a note to let me know what you'd like to see!
