It's 2009. 64-bit technology offers clear benefits for security and performance—so why is it taking so long for people to adopt it?
I've been around computers long enough to remember the shift from 8-bit CPUs such as the Zilog Z80 to 16-bit CPUs such as Intel's 80286, and then to 32-bit units such as the Motorola PowerPC. At each stage, people eagerly adopted the new CPUs because the benefits in performance and memory addressing capability were quite clear. Adoption hasn't been the same for the move to x64 hardware and x64 versions of Windows, though, even though the scalability and security benefits of x64-based computing are just as obvious. Exchange Server 2010 and Exchange Server 2007, for example, make great use of the additional address space potential by letting you have extremely large Extensible Storage Engine (ESE) caches, reducing disk I/O by a large margin.
One objection to "going 64" is that 64-bit computing makes economic sense only for some types of application servers. There's certainly some truth to that argument, but it runs up against a sizable roadblock: There won't be a 32-bit version of Exchange 2010, even for test use. See the Exchange Team blog post "Is there a 32-bit version of Exchange 2010?" for this announcement. Some users are raising objections that they still need 32-bit versions. Are these objections valid?
The answer varies according to which component of Exchange we're actually talking about—but those components are all built from the same code base! For example, there are certainly customers who need to perform Exchange administrative tasks from 32-bit workstations. In Exchange 2007 and earlier, they could install the admin tools on their workstations, but because there won't be a 32-bit version of these tools for Exchange 2010, that option's off the table. The good news is that there are offsetting compensations and workarounds:
- Exchange 2010 fully supports remote Windows PowerShell so that you can securely log on to a remote machine and use PowerShell—and the Exchange Management Shell (EMS)—to administer it. You can even use this procedure between different Exchange organizations; for example, I can fire up PowerShell at work and use it to manage my home domain remotely. (Granted, if you're not a PowerShell geek, you might not find this an exciting capability!)
- The new role-based access control (RBAC) features in Exchange 2010 provide extremely fine-grained control over what administrators can do. RBAC lets you control not just which EMS commands—and, thus, Exchange Management Console (EMC) features—users can use, but even which parameters or switches they can specify. This amount of control makes it much easier to match capabilities with roles.
- Many of the administrative functions available in EMC are now present in the new web-based Exchange Control Panel (ECP), which can be run from any machine that can run OWA; that means that non-Windows machines now have a fair shake).
- Using RDP to remotely log on to the server and work remains a completely viable solution.
One use case that I haven't found a good solution for is that of having a Help desk that uses EMC solely to perform user management and provisioning tasks. These tasks are accessible through remote PowerShell, but they're not available through the ECP. A web-based provisioning tool is probably the best solution for these users.
This discussion has so far avoided any mention of 32-bit versions of Exchange itself, such as the ones commonly used for building test or demo environments. Here, I'm sad to say, the writing is on the wall: If you want to work with Exchange 2010, you'll need a 64-bit-capable machine and a 64-bit OS to run it on. That might mean investing in new lab hardware, laptops, or other resources, but there's no way around it—once you go 64-bit, you'll never go back!
Related Reading: