Last week, I described Microsoft's recently announced platform strategy for moving its server products to the x64 platform and, over time, off of x86. Some products, such as Windows Server, will move to x64 gradually, and will support both x86 and x64 in the coming generation. However, others, such as Microsoft Exchange 12, the upcoming messaging server revision, will ship only for the x64 platform, a decision that could leave some users in the lurch. The problem isn't so much the hardware as it is the software. As Microsoft notes, almost 70 percent of all servers sold in third quarter 2005 used x64-based hardware, and those numbers will only increase as PC makers phase out x86 hardware in 2006. The real story here, of course, is that the vast majority of x64 servers rolled out worldwide are using 32-bit x86-based versions of Windows Server, not x64-based versions. So moving to 64-bit server products such as Exchange 12 will require corporations to install new versions of Windows Server as well as Exchange.
The situation is further complicated because the x64 versions of Windows Server 2003 don't support upgrading from the more common x86 versions. So companies wanting to use x64 software products will need to perform clean installations of the OS, wiping out whatever system, applications, and services were previously installed. Therefore the installation will require extra time, planning, and testing, which can of course lead to additional costs as well.
Microsoft argues, correctly I think, that the benefits to x64 are often greater than the risks and costs. But although this argument will be largely academic a few years from now, the current migration period, in which today's 32-bit systems are slowly phased out in favor of more scalable x64 solutions, will be painful for many and even prohibitively expensive. On the plus side, most software written for x86 will run fine on x64 OSs; that means that many of your custom applications will make the transition with little or no changes.
But it's you, the Windows IT Pro UPDATE readers, who will need to make this transition. So last week, I asked you what you thought of Microsoft's decision to aggressively move to the x64 platform. Predictably, your feedback was invaluable and will, I hope, help Microsoft evaluate its decision in a slightly different light.
Many readers were somewhat resigned to what they see as a steady series of unreasonable requirements for upgrading to new Exchange versions. Over the years, various Exchange product versions have required specific Windows Server versions--first Windows NT 4.0, then Windows 2000 with Active Directory (AD), for example. Requiring customers to install both x64 hardware and an x64 version of Windows Server to get Exchange 12 isn't welcome, but it's not surprising either. This, I think, is the toughest part of Microsoft's plan: With Exchange 12, customers will need to buy completely new hardware preloaded with Windows 2003 x64, or they're going to need to wipe out existing servers and install the x64 OS from scratch. That's a lot of work and expense.
One might think that Software Assurance (SA) and similar volume licenses must offset some of the upgrade pain. But for customers who recently rolled out high-end Xeon hardware that doesn't include x64 capabilities, the benefits of getting Exchange 12 (or Windows 2003 x64) as part of their software subscription doesn't always outweigh the pain of having to wipe and reload.
On a related note, there seems to be a bit of a backlash rising against the perpetual upgrade cycle that Microsoft requires customers to make to take advantage of new technology. Many noted that they're still running ancient versions of Windows and Exchange--NT 4.0 or Windows 2000 with Exchange 5.5, for example--because those systems still meet their needs. Obviously, these are small companies, but as a percentage of the overall market, I have to think they constitute a fairly large part of the customer base.
This last point hints at what I consider to be the second biggest problem with Microsoft's plans. Are x64 hardware systems really as pervasive as Microsoft thinks they are, with regards to the installed base? If you break down Microsoft's core markets into three logical segments as the software giant does--small businesses, medium businesses, and enterprises--I think you'll discover that the spread of 32-bit and x64 hardware systems in deployment today varies widely by segment. Readers who responded were of two minds. First, many were surprised to discover that they had been purchasing and using x64 servers--albeit with 32-bit OSs--for some time without even realizing it. But many others were adamant that they had never seen an x64 server in deployment. And for some companies that use hardware for several years, the prospect of upgrading simply to get the next Exchange version was a bit hard to understand.
What's fascinating is the disparity in responses. For every outraged response, there was a positive message, full of hope about the 64-bit future. Many people believe, as Microsoft does, that the transition from 32-bit technology to 64-bit technology will be more seamless and less painful than the previous transition from 16-bit to 32-bit. That it comes with better security features and a sudden and almost exponential scalability boost is just the icing on the proverbial cake.
The server world is moving to x64 regardless of my opinion or your requirements. But I'd like to see Microsoft do something positive to make the x64 transition less painful. This could include an OS trade-up program, similar to what the company offered to Windows XP users on the desktop, which would obviate any direct OS upgrade costs. Microsoft could also provide x64 upgraders with a number of free support calls or provide similar services that would allay fears and ease the upgrade burden. Unfortunately, Microsoft's Technology Advancement Program, which allowed customers with 32-bit Windows 2003 versions running on x64 hardware to exchange those products for the equivalent x64 versions, expired in July 2005. It might be a good idea to at least reconstitute that program for Exchange customers.