In reading through comments regarding Exchange 2007's lack of 32-bit support and confusion around why Microsoft decided to provide a 32-bit "test" version of Exchange 2007, I thought I'd offer some facts about this version and some possible reasons that Microsoft went 64-bit-only with Exchange 2007.
First, as advertised, the 32-bit version is for testing only. Many people like to test server software in a virtual environment before making the production plunge. Take note that Virtual Server 2005 R2 does not support 64-bit guests virtual machines. Even VMware ESX 3.0 only had experimental support for 64-bit guest operating systems. ESX 3.0.1 now includes full support for 64-bit guests, but this is a recent release. Sure, desktop virtualization packages have supported 64-bit guest OSs for a while now, but the enterprise-variety virtualization offerings are just catching up to this.
In short, had Microsoft opted to skip a 32-bit testing version, they would have locked out anyone who wanted to test the product on older servers -- those that do not support 64-bit. I don't think that releasing a 32-bit unsupported test version was irresponsible and it shouldn't be confusing. It's for testing, runs on just about any hardware you have laying around and is easily available.
I think that Microsoft's decision to support only 64-bit hardware and software for Exchange 2007 is also defensible. How many of you do in-place upgrades of your critical infrastructure? I consider Exchange critical infrastructure. When I perform an upgrade to Exchange, it's generally time to buy new hardware anyway. I've never done an in-place Exchange upgrade, and probably never would. Of course, things are very likely different in other places and in-place upgrades may make sense. For you, this option simply isn't on the table with Exchange 2007.
Exchange as a memory hog
Second, Exchange is a memory-hungry application. It wants and needs a lot of RAM to operate. With new features in Exchange 2007, more RAM will be necessary. Without special extensions, a 32-bit platform tops out at a total of 4GB of RAM. With a 32-bit platform and through the use of the /3GB switch, you could allocate 3GB for user mode addressable memory for caching. This was the limiting factor for expandability in many Exchange organizations. With a complete 64-bit platform, Exchange 2007 can use all available system RAM for whatever it wants. This results in improved I/O performance, which means that more users and be housed on fewer servers.
64-bit is here to stay
Finally, 64-bit is here and is not going away. Just about any new server you purchase will support 64-bit applications and there isn't an increased licensing fee for a 64-bit version of an OS. While there may be driver issues with 64-bit computing, I think these issues are largely related to Vista. Enterprise-grade hardware drivers are working great on 64-bit.
Would it have made sense for Microsoft to provide both 64-bit and 32-bit versions of Exchange for production? One of the primary Exchange 2007 design goals was to reduce overall I/O while supporting larger mailboxes with more features, such as Unified Messaging while at the same time reducing the overall TCO for Exchange. You could add disks until you're blue in the face, but you won't get the same performance you get by adding more RAM to the Exchange server to be used for caching. Given this goal, I don't think it would have made sense for Microsoft to support 32-bit Exchange 2007.
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 with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at email@example.com.