Software optimize

Reduce hardware needs and ease administration with Exchange 2010

Exchange 2010 builds on many of the good aspects of Exchange 2007, and organizations migrating to Exchange 2010 will be able to do so with less hardware. Scott Lowe discusses some of the new server-side features coming in Exchange 2010.

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.

Summary

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?

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

9 comments
Steve
Steve

Your article seems contradictory. It's called "Reduce hardware needs and ease administration with Exchange 2010" but from what I am reading, Exchange 2010 requires more hardware - especialy when you look at the new (although very welcome) Database Availability Groups. These need a lot more storage than you had in the past.

HCream
HCream

Forget all these fancy UC stuff. I'm still waiting for a solution to one of the fundamental problems with business email: how to easily include big file attachments with message. Sure there are third party solutions. But shouldn't a mature product like Exchange possess this function?

mredgar2005
mredgar2005

I wonder how painful/painless it'll be to move from our Exchange 2003 to Exchange 2010. Hopefully it's possible without having to migrate to Exchange 2007 first.

chamblin
chamblin

OWA works well in almost all browsers now. Big improvement for those Linux and Mac end users.

HaroldHO
HaroldHO

I haven't had a good experience with any Microsoft direct upgrade - I would rather they not make it available than have it be less stable than a fresh install + migration. We're in a similar situation with the MSCA giving us Exchange 2010 availability very soon here. Sure, it's a hassle having to buy more hardware, but the retired Exchange 2007 hardware is not wasted - as soon as you're migrated and the Exchange 2007 systems are all entirely removed from the environment, you can eventually re-purpose the hardware. At the end of the day, though, it's just as you said - the changes between 2007 and 2010 are evolutionary, where 2003 to 2007 was revolutionary. I think we'll ride 2007 a bit longer and see if there are any advantages 2010 will bring us down the line.

ncapconsulting
ncapconsulting

Please describe the "issue" with large attachments. Both natively, and with integration, Exchange supports large attachments. What is YOUR issue with large attachments and Exchange?

Justin James
Justin James

What exact problems are you having with Exchange and large attachments? And how large is "large"? J.Ja

Justin James
Justin James

They pulled the "no direct upgrade path" on me with OCS 2007 R2 as well, and I was less than thrilled. I don't care, in terms of the hardware itself; all of this stuff is running in VMs anyways, for me. But I hate what it does for me in terms of migration. Anything that was pointing to the old server needs to be changed, for example. Luckily, I had the foresight to CNAME the Exchange server, and point many services at the CNAME, not the ANAME. Not everything is like that. On the plus side, we only put in Exchange last year, so it isn't like there is a lot of cruft built up or hidden legacy apps out there. On the other hand, I am *still* finding things pointing to servers that haven't been around for a while. Earlier this week, while doing a packet capture to debug a problem, I discovered that our online store had been trying to use an SMTP server for an ISP we stopped using over 2 years ago... great. J.Ja

Justin James
Justin James

The default is something like a 10 MB message size I think... probably just hasn't found where to change it. J.Ja