One question that Exchange administrators often ask me is how they can get a 32-bit version of Exchange 2010. Microsoft first moved Exchange to a 64-bit platform in Exchange 2007 but they also issued a 32-bit version to be used for testing purposes. The 32-bit version was also used for training, lab environments, demonstrations, and some limited administration purposes (such as making schema changes to the Active Directory in advance of rolling out Exchange 2007), but Microsoft never intended the 32-bit version to be used in any serious sense.

While it might seem to be reasonably easy to spin off a 32-bit version alongside the normal 64-bit version during the engineering build process, making this software available creates some cost for Microsoft, not to mention the technical complexity to maintain the build integrity such as making sure that bugs aren’t introduced by having to create versions for two platforms. You can argue that Microsoft gains a lot from the 32-bit version by allowing people to become more familiar with Exchange because they can install it on a virtual machine running on a laptop. The same environment can be used to test Exchange, to demonstrate it to new customers, or even to validate statements that appear in books. All of these activities are valid and important but Microsoft decided not to go ahead with any further 32-bit builds during the Exchange 2010 beta cycle. This decision was taken over 18 months ago so it’s surprising that people are still asking… or maybe not!

Microsoft’s logic is that they needed to make a 32-bit version available for Exchange 2007 because it was the first version to move to 64-bit and companies needed help to make the transition. They also point out that generating multiple versions of Exchange consumes a considerable amount of engineering resource that they prefer to use to develop new functionality and fix bugs in a drive for a more functional and higher-quality product. To put this situation into context, Exchange 2010 consists of many million lines of managed code (mostly C#). Even with fast systems, compilation of Exchange’s source code still takes hours. Even then, all you have is a version that may contain bugs that have been introduced by new code checked in since the last build, so before the version is released, Microsoft puts it through a huge battery of regression and functionality tests to ensure that the code is solid.

During development, Microsoft builds a new version of Exchange daily following a cycle of check-in, compilation, and testing. The test suite is exacting because customers deploy Exchange in wildly different circumstances, so Microsoft has to ensure that Exchange works in a variety of scenarios. A test of a single bug fix therefore has to be run multiple times to test the code against all of the scenarios where Microsoft expects Exchange to function – virtualized and “real” servers, in a DAG or standalone, on a server with one role or one that supports multiple roles, potentially against different versions of the Windows O/S, and so on.

With such a large code base, it should come as no surprise that the Exchange development group fixes hundreds of bugs weekly. Many of these bugs are small (for instance, a spelling mistake in a help file or an inconsistency in translation in one of the language versions) while others are more fundamental. All of the fixes have to go through regression testing to make sure that they don’t break something else and as the end of the development cycle approaches, increasing focus goes onto fixing the must-fix bugs to ensure that Exchange meets its goals for features and quality. Given all of this activity and cost (financial and people), it’s not surprising that the Exchange development group wanted to stop work on the 32-bit version. It’s also worth noting that the same discussion is going on with every Microsoft engineering group with the result that products such as SharePoint 2010 is only available as a 64-bit release running on Windows 2008 with a dependency on the 64-bit version of SQL Server 2008 or SQL Server 2005.

The bottom line is that Exchange 2010 is a pure 64-bit environment. There is a consequential need to invest in 64-bit hardware for use in labs, training centers, or other demonstration and testing activities as well as to perform management of Exchange 2010 servers. Not everyone runs 64-bit laptops or workstations, so there’s obviously some cost involved to upgrade hardware and software to create a suitable environment based on virtualized servers (Hyper-V or VMware) or terminal services.

Depending on their BIOS, many current 32-bit PCs can support virtualized 64-bit guest systems. For example, VMware workstation running on Windows Vista is capable of supporting an Active Directory domain controller and two Exchange 2010 servers running on Windows 2008 R2. Things get slow when you run two or more virtual servers as 32-bit OS cannot address more than 3GB of memory and laptops are further handicapped by their slow disks. If you want to run virtualized Exchange on a laptop for development or test purposes, you should use the 64-bit version of Vista or Windows 7 equipped with at least 6GB of memory and a fast external drive (such as an SSD drive). My experience is that modern laptops configured in this way deliver a very usable platform.

If you want to run the Exchange 2010 version of the management console, you’ll need to use a 64-bit workstation running Vista SP2 or Windows 7. The workstation has to be joined to a domain, but not necessarily the domain where Exchange 2010 exists, as Kerberos is used for authentication and to encrypt the remote PowerShell channel used for management operations. And of course, the option still exists to manage Exchange 2010 over RDP using the Remote Desktop Connection application that’s built into Windows XP, Windows Vista, and Windows 7. This application allows you to connect to any Exchange or other server in your organization and manage it as long as you can create a connection to your network. I’ve managed Exchange servers with RDP over varying connections around the world, including using a VPN connection established using the Internet Sharing application on a Windows Mobile phone when travelling on a train through the Netherlands.

No further 32-bit builds of Exchange will appear and the future is entirely 64-bit, until of course the time comes to upgrade to a 128-bit, 256-bit, or whatever new number of bits future hardware and software platforms require.

– Tony