Why you absolutely cannot upgrade Windows on an Exchange server

The arrival of Exchange 2013 SP1 has spurred many companies to consider upgrade projects. Choosing the right operating system for Exchange 2013 is a big part of the plan. I like Windows 2012 R2... But what if you have Exchange 2010 servers on Windows 2008 R2? Can you first upgrade Windows to Windows 2012 R2 before commencing your Exchange upgrade? Or even Exchange 2013 CU3 servers on Windows 2012? The answer is NO. Don't even try. Take a pill. You'll feel better and the temptation will pass.

In September 2012, just before the RTM version of Exchange 2013 shipped, I wrote about choosing between Windows 2008 R2 and Windows 2012 as the operating system for Exchange 2013 deployments. At that time I concluded that an equal case could be made for either version of Windows, but that it made sense to select the more modern version because it would last for the supported lifetime of Exchange 2013. As we’ve seen with Exchange 2003, that could be a decade or more.

One of the reasons why you have to select the operating system before starting to deploy Exchange 2013 is that this is a one-time vote. You don’t get to upgrade Windows 2008 R2 to Windows 2012 or Windows 2012 to Windows 2012 R2. For as long as I can remember, it has been the case that once Exchange went on a Windows server, that server was, if you will, set in stone. You can apply the fixes distributed by Windows Update but that’s about the sum of the story when it comes to modernizing the operating system. As TechNet summarizes the situation in one precise sentence “You can't upgrade Windows when Exchange is installed on the server.”

The fact that Exchange 2013 SP1 now supports Windows 2012 R2 and that R2 delivers some advantages in that it is easier to deploy (fewer prerequisites to install) and technical innovation (like the changes in Failover Clustering that underpin the simplified DAG) has provoked some questions about why Microsoft insists that Windows can’t be upgraded after Exchange is installed. It’s a good question. Here’s my take on the reason why.

First, Exchange deeply embeds itself into Windows when it is installed on a server. It could be the case that Exchange uses more Windows components than any other server application (the topic surely for a fascinating debate over drinks). The intertwining between Exchange and Windows creates a challenge to engineer an installation procedure that can upgrade a Windows server when Exchange is installed. Who owns this responsibility? I can’t imagine that the Windows team would enjoy it very much because then they’d have to provide the same facility to other server products like SharePoint.

Second, it’s not just a matter of Exchange. Most on-premises deployments use third-party software alongside Exchange and a Windows upgrade would have to take these products into account. That’s a heap of complexity that is impossible to manage in any practical sense.

Third, if you run Database Availability Groups (DAGs), then you know that all of the DAG members must run the same version of the operating system (and, as far as possible, the same version of Exchange 2013). DAGs are built on top of Windows Failover Clustering and this component has evolved and changed from Windows 2008 R2 to Windows 2012 to Windows 2012 R2. Attempting to upgrade a DAG member from Windows 2012 to Windows 2012 R2 and continue to work smoothly when cluster services are mismatched is not a good scenario. In addition, DAGs exist to provide high availability, and messing around with server operating systems sounds like a good way to compromise that feature.

Fourth, consider the massive testing matrix that you’d create if operating system upgrades were supported (and all of the technical challenges were solved to allow the upgrades to happen). It’s hard enough for Microsoft to test new builds of Exchange as it is – adding even more complexity to the test mix seems like an accident waiting to happen.

You might be disappointed because you can’t upgrade Windows when Exchange is present. Don’t be. It’s not worth the heartburn. Accept the situation and accept the wisdom that deploying Exchange on a nice fresh new operating system on new hardware is the best way to create a reliable and robust platform for enterprise messaging. We learned this when Exchange 2007 made the transition from 32-bit to 64-bit software and the practice has been well proven since.

And to answer the inevitable question of what is the best operating system for Exchange 2013 SP1 (and later builds). Well, my personal preference is to use Windows 2012 R2. It just makes sense to use the most modern operating system if your operational environment and business needs accommodates the choice. I know that this isn’t always the case, but it makes sense to me.

Follow Tony @12Knocksinna

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×