Major changes were introduced in Exchange 2007. From the elimination of 32-bit servers in production environments (which, by the way, led to major performance gains as a result of lower overall I/O) to the rewritten management interface to the introduction of unified messageing and the heavy underlying reliance on PowerShell, Exchange 2007 has proven to be a solid, reliable system. I’m extremely fond of Exchange 2007. I worked with Exchange since its 5.5 days, and Exchange 2007 was a great leap forward.

Now, with Exchange 2010 seemingly around the corner (another public test build was released), I am starting to think about what it can bring to the table so I can make a determination about whether to deploy the new system at Westminster College. Upon its release, Exchange 2010 rights will be added to our Microsoft Campus Agreement, making the upgrade decision one based more on time than dollars. That’s one major advantage to working in higher education!

It’s obvious Microsoft realizes that SaaS-based email providers are nipping at the company’s heels. Exchange 2010 includes a number of improvements targeted directly at lowering total cost of ownership and making that outsourcing arrangement just a little less sweet. Microsoft is also setting up Exchange for its own SaaS/cloud offering, and the improvements in Exchange 2010 help to address this business goal.

Reduced I/O footprint

One of Exchange 2007’s biggest improvements was in the area of a reduced I/O footprint. This improvement was largely due to Exchange 2007’s reliance on a complete 64-bit architecture, along with all of the benefits that come with 64-bits, such as increased RAM support.

Exchange 2007 also uses a larger page size than older Exchange servers, resulting in fewer I/O calls. As a result of the reduction in storage performance requirements, Exchange 2007 servers can support many more mailboxes than their Exchange 2003-based counterparts.

Exchange 2010 takes this I/O reduction to the next level, partially by further increasing the page size to 32K. Between this and other improvements, Exchange 2010’s I/O needs are reduced an additional 50% to 70% from Exchange 2007.

This means that a single Exchange 2010 server can support even more mailboxes than Exchange 2007 systems. It also enables broader storage support in Exchange 2010, including the use of less SATA disks for mail storage.

No more storage groups

If you’ve worked with Exchange 2007, particularly in a high mailbox availability scenario, you’ll understand why Microsoft eliminated storage groups in Exchange 2010. In a clustering-type situation, Exchange 2007 only allowed a single database per storage group anyway, so the storage group simply became a redundant management entity that got in the way. With storage group functionality effectively moved to the database level, associated PowerShell cmdlets are also either removed from or modified in Exchange 2010.

SCCs and LCR are gone

Single copy clusters (SCCs) and Local Continuous Replication (LCR) were introduced in Exchange 2007 as ways to achieve a semblance of high availability with a single server or a single storage array. These two availability techniques are removed from Exchange 2010, which focuses more on multi-server high availability mechanisms.

Database Availability Groups

Along with some of the other changes to storage and availability features, Exchange 2010 also introduces much easier ways to handle high availability. Exchange 2007 — especially in concert with Windows Server 2008 — significantly simplified the entire process of clustering mailbox server roles.  Exchange 2010 takes this simplification to a new level.

At first, it may look like Microsoft has eliminated, along with SCR and LCR, the other types of clustering — CCR and SCR — from Exchange 2010. In reality, with the introduction of Database Availability Groups, these kinds of clusters are still supported, but the Exchange administrator doesn’t need to worry as much about the underlying clustering component, as the cluster configuration gets handled by Exchange tools doing the Windows clustering work out of sight of the administrator.

A Database Availability Group can support up to 16 copies of a single database, so you can be certain that your data never gets lost. Further, whereas no other roles could coexist with the clustered mailbox role under Exchange 2007, other server roles can now coexist with highly available mailbox servers, reducing the overall hardware requirements for Exchange yet another notch. With Exchange 2010’s new clustering capabilities, availability is achieved at the database level rather than at the server level. Under Exchange 2007, when a single database failed, the entire server and all mounted databases would need to be failed over to another node. This is no longer the case.

As Microsoft puts it, databases are no longer closely tied to a single mailbox server but are really mobile throughout the Exchange organization depending on the company’s needs. As a result, there is a significant to change to how Outlook clients interact with Exchange. In Exchange 2007, Outlook clients communicate directly with mailbox servers, bypassing the Client Access Server (CAS). Exchange 2010 changes this behavior, routing Outlook clients through CAS so that the clients are connected to the correct mailbox server, which could change depending on availability situations. This could result in additional hardware being necessary to support the increased needs of the CAS role. It also means that you can move a user’s mailbox on-the-fly — even while a user is actively accessing it.

Planning to upgrade? Think again

When Exchange 2007 was released, it made a lot of sense that in-place upgrades from older versions of Exchange weren’t supported; after all, Exchange 2007 is a 64-bit application, while older versions lived in 32-bit land, making the in-place option impossible. With Exchange 2010, not much has changed. For some reason, Microsoft is not supporting in-place upgrades from any version of Exchange, including Exchange 2007. This will prove frustrating for many Exchange shops that will once again have to pony up for new hardware rather than just use what they have.

Exchange 2010 also drops support for Windows Server 2003 as the host OS, instead focusing on Windows Server 2008 and Windows Server 2008 R2; in fact, the only version of Exchange supported on Windows Server 2008 R2 is Exchange 2010.

Unified Messaging gets better

Anyone need a message waiting indicator (MWI)? In Exchange 2007, MWI software was a third-party add on that added expense and complexity to integrate a simple feature that many thought should be included in any reasonable Unified Messaging solution. Exchange 2010 adds message waiting capability, along with call answering rules, SMS/text messaging-based missed call, voicemail notifications, and a text-based preview of the contents of a voicemail message.


Exchange 2010 is definitely an evolutionary step in the Exchange line, but it does take great leaps in a number of areas. While there are some curious frustrations, including the lack of an in-place upgrade option, Exchange 2010 includes compelling new features, particularly for organizations that have not yet made the move from Exchange 2003.

In a future post, I will discuss user feature enhancements in Exchange 2010.

Want to keep up with Scott Lowe’s posts on TechRepublic?