By now, you know that the next version of Microsoft Exchange Server, code-named Exchange 12, will run only on 64-bit AMD or Intel systems (there will be no Intel Itanium release). Why? Microsoft has based this decision on the belief that the world is moving rapidly to a point at which 64-bit hardware is the norm for customer deployments. On top of that, moving Exchange to a 64-bit platform solves several of the product's technical challenges. Will this decision cause customers to slow their plans for Exchange 12 deployment, or will it make the next Exchange version more attractive than ever?
Microsoft's Dilemma
Across the board, the parameters that dictate the potential performance of a messaging server such as Exchange have changed during the past decade. Messages are larger. Mailboxes are larger. Consolidation is a continuing theme. Users access email more often and through more varied methods: PDAs, Research In Motion (RIM) BlackBerry devices, smart phones. Microsoft had already told us that Exchange 12 would be the first true 64-bit Exchange version. The company's dilemma was whether to continue providing a 32-bit version of Exchange alongside the 64-bit version.
You might argue that retaining a 32-bit version would let customers move to Exchange 12 on their existing hardware. Why wouldn't Microsoft make Exchange 12 the last version to support 32-bit hardware and so prepare the user community for the necessary hardware changes in the next release?
First, that release might not appear until 2010, and a lot of the servers sold in late 2005 are already 64 bit?ready. By the time Exchange 12 ships (most likely in early 2007), finding 32-bit servers might already be difficult.
Second, keeping two code bases would increase Microsoft's engineering expenses as it develops, tests, debugs, packages, and translates Exchange. From an engineering perspective, staying with a 32-bit version would prevent Microsoft from addressing some of the problems that prevent scaling of the Exchange Information Store—problems that include the virtual-memory fragmentation that limits cluster state transitions in Exchange Server 2003 or Exchange 2000 Server, and limits on how many databases a single Exchange server can support. Other 32-bit troubles include kernel-mode problems. The memory required to handle delegate access to calendars and mailboxes, or the number of client connections that arise when users access Exchange through a variety of devices, add to the overall demand on a server. For example, you might think that your server supports 2000 concurrent mailbox connections, but when you add all the other connections that devices and programs make to Exchange, you find that the actual load is increased by 20 to 30 percent. That increase doesn't help performance, especially on servers that are close to the limit of acceptable response time. See the sidebars "I/O, I/O" and "Solutions in Store" for more examples of 32-bit?related problems and the 64-bit solutions.
Virus scanners, which are an absolute necessity for Exchange servers, also use kernel-mode memory, thus decreasing the amount available to other processes. Still another problem is the kernel-mode exhaustion that can happen when you home more than 10,000 mailboxes on a public folder server.
Your initial reaction to the decision to support Exchange 12 only on 64-bit platforms might be to take a sharp breath. But when you look at these factors, the decision is logical. It might even prove to be welcomed— provided that Microsoft delivers a quality product at the end of the Exchange 12 development cycle.
Your Dilemma
Regardless of whether the decision to go with a pure 64-bit implementation is a good one, your primary question is likely what effect the decision will have on your Exchange deployment. Several factors are going to come into play if you mean to find the answer to that question.
The first factor is hardware. Purchasing pure 32-bit systems from here on is probably a bad idea, unless you plan to replace those systems within the next 2 years. If you plan to deploy Exchange 12 anytime in the next 3 or 4 years, it makes sense to invest in future-proofed Intel or AMD systems that are capable of running 64-bit Windows and Exchange. But be aware that even with such systems, you probably aren't going to be able to perform an in-place upgrade directly from Windows Server 2003 and Exchange 2003 to 64-bit Windows and Exchange 12, simply because of the sheer complexity involved in such an upgrade. I expect that Microsoft will require you to deploy new 64-bit Windows and Exchange servers; you'll then need to move mailboxes across from the Exchange servers that you're using now. This approach isn't likely to be a problem for enterprises that run several servers, but if you have only one Exchange server or if you operate in a branch-office environment (in which deploying multiple servers at branch locations is difficult), you'll probably want to wait to move to Exchange 12 until you're ready to replace your hardware.
The second factor is testing. After all, you'll want to test the new software before you deploy it. Administrators, consultants, and Exchange architects also use test environments to deploy and validate new versions of the software, patches, and products that run alongside Exchange. These test environments range from complex, multiserver installations that mimic all the attributes of a company's production environment to configurations that run within a virtualized environment on a laptop. Obviously, you'll have to rebuild your test environments to cope with Exchange 12. For those who aren't expecting it, this necessity will come as a surprise expense and will limit the ability to roll out Exchange 12. Microsoft has stated that it will generate 32-bit Exchange 12 versions for testing during the early part of the development process (early 2006), but such versions surely will omit capabilities that are possible only on the 64-bit platform—features that you'll want to test. Furthermore, these 32-bit versions will eventually peter out as Microsoft's attention focuses on getting the 64-bit version out the door. For example, you can't expect Microsoft to do any real performance testing on a 32-bit version that it plans to discard.
Previous
Register
