One of the interesting decisions awaiting those who want to deploy Exchange 2013 is the operating system to use. The choice is pretty straightforward. You can use either Windows 2012 Server or Windows 2008 R2 SP1. Is the choice then between the well-proven record of the latter and the new promise of the former? Let’s discuss.
An obvious influence on the debate is the way that Microsoft now treats upgrades for new versions of Exchange. Whereas B2B (build-to-build) upgrades are supported within a specific version of Exchange, you haven’t been able to upgrade one version of Exchange to a newer release ever since Microsoft discovered the joys of forcing customers to deploy new servers for Exchange 2007.
Of course, Microsoft had a great covering story when Exchange 2007 hove into view. The complexity of moving a server running a 32-bit version of Windows and a 32-bit version of Exchange to 64-bit versions of the OS and email server were just too horrendous to be contemplated. Panic would ensure if Microsoft even attempted such a feat, so they simply said “we’re making this real easy for you – buy some nice new 64-bit hardware and have a nice day.”
And so it came to pass that ever since we’ve experienced easy upgrades while making it possible for the friendly representative of our preferred server vendor to make their quarterly sales target. From Microsoft’s perspective, the decision to avoid in-place server upgrades makes life very much easier for the engineers who maintain Exchange’s setup program as well as eradicating a whole heap of potential cost that would otherwise be necessary to code around all the potential “what if” cases involved during in-place upgrades.
One of the obvious difficulties that in-place upgrades would run smack into is a need to upgrade databases. In the early days of Exchange this problem didn’t exist because Microsoft didn’t upgrade the database schema or internal layouts and roughly the same JET database persisted from Exchange 4.0 in 1996 to Exchange 2003 in 2002. Sure, tweaks happened to accommodate structures such as Storage Groups, but not the kind of fundamental overhaul that we’ve seen since in the effort to drive Exchange’s I/O profile to accommodate low-cost storage, introduce native data protection, and overall make Exchange’s mailbox databases perform better as each release rolls out. Databases are now “upgraded” to a new version by moving mailboxes to servers running the new software. This is a pragmatic and effective method of populating the databases and avoids any need to run an in-place database and schema transformation that might involve hundreds of gigabytes of data. You know how long ESEUTIL takes to rebuild a database. Now figure out how long it might take to install a new version of Exchange if all the mailbox databases on a server had to be upgraded at the same time.
Getting back to the original question, if you’re going to use new server hardware, there is a natural attraction in selecting Windows 2012 Server as the preferred platform for Exchange 2013. After all, it’s bright, new, sparkling, and Jeffrey Snover (the lead architect for Windows Server) says that the new OS is very good indeed. All in all, given that most Exchange 2013 servers can be expected to be in production until the time comes to deploy the next major release (let’s say Exchange 2018 as you might ignore an interim release) or you decide to go “all-in” the cloud, it seems to make a lot of sense to use an operating system (patched appropriately) that won’t be ten years old when Exchange 2013 runs out of steam.
On the other hand, Windows 2003 SP2 has done a splendid job of supporting Exchange 2007 and it’s getting near to ten years old at this point, so maybe an older operating system is best because it’s been well debugged and sorted and is less likely to run into the kind of unforeseen headwinds that a new OS can meet. It’s also fair to say that some companies have very well-developed operational and management processes built around Windows 2008 R2, including third-party software, and considerable work is necessary to upgrade these structures for Windows 2012, which might then delay the deployment of Exchange 2013.
Every company is different and no doubt there are specific circumstances within your company that will tilt the decision one way or the other. What’s for sure is that at this point there are no technical reasons why Windows 2008 R2 can’t continue to be the operating system of choice for an Exchange 2013 deployment, a statement that is also valid for Windows 2012. Your choice. Heads or tails?
Follow Tony @12Knocksinna
