The computing world is full of religious debates. I use the word religious to indicate that most of these debates are based on beliefs that are difficult to quantify and sometimes hard to explain but are sincerely held. If you've been in IT for a while, you probably have your own favorite example. Emacs or vi? Novell NetWare or Windows NT 3.1? Exchange or IBM Lotus Notes/Domino? Macintosh or Windows? You get the idea.
The Exchange community isn't immune to these debates, although for the most part we're a pretty harmonious group. Recently, however, I've noticed a new outbreak of a familiar debate: When upgrading an Exchange server, should you perform an in-place upgrade or a clean installation? Each approach has its adherents, and the high priests in Redmond haven't provided any clear guidance. In this case, the Old Testament prophet Isaiah's admonition ("Come now, and let us reason together") is probably appropriate. Is there a preferred way to do an Exchange upgrades?
Let's start with the pro-starting-over faction. There's no question that a production Exchange server can eventually grow a layer of unproductive crud in the form of assorted files and executable bits that were once needed but are now superfluous. Upgrading a server by performing a clean reinstall of the OS (and service packs and security patches) gives you a clean start, with an opportunity to remove any lingering garbage objects that might have taken up residence in your Active Directory (AD) topology.
Of course, doing things this way is a burden; the obvious problem is that a clean installation requires that you perform some tricks. If you just take an existing box and "pave" it by reinstalling Windows, you're likely to break its ability to join the domain, which in turn will break Exchange. It's safer to remove Exchange (thus removing the server from AD), disjoin the computer from the domain, reinstall, rejoin, and reload Exchange. This process obviously takes time, and it certainly requires you to be careful about backing up any mailbox data on the server. You can cut down the time required, however, by using the Ed Crowley Server Move Method to move mailboxes to a swing server before you rebuild the box, which helps somewhat.
On the other side of the argument, an in-place upgrade offers what seems like a simple proposition: At least in theory, you can upgrade Windows and Exchange (separately, of course) without having to remove or reinstall. You still have to make a good backup first, of course, but when in-place upgrades work smoothly they can save you a lot of time.
The "when" in the above sentence is the killer, however. Microsoft makes an effort to ensure that its upgrade code works in a wide range of circumstances, but the company can't test everything, particularly when you factor in all the additional products that might be found on a typical Exchange server. For example, what if your backup product installs a driver that isn't compatible with the version of Windows you just upgraded to? (The answer is "it depends," which isn't very comforting.)
I guess I should make my own prejudices clear. I lean toward the clean-installation side of the argument because when I'm upgrading a system I want to eliminate as many variables as possible. I typically cheat a bit by performing a parallel installation of Windows whenever I'm not 100 percent sure that the target hardware has a fully supported set of drivers so that I can fall back to the original Windows version if need be. However, when pressed for time, I've been known to cheat by performing an in-place upgrade if the target server is relatively clean.
The interesting question is what upgrade options Exchange 12 will offer. Microsoft has publicly stated that Exchange 12 will use the Windows Installer (a requirement to comply with the Common Engineering Criteria), which should make it easier to perform a successful in-place upgrade. However, depending on how Microsoft chooses to support 64-bit Windows, in some circumstances you might have to perform a complete reinstall when you upgrade. I'm sure more details will be forthcoming as part of the Exchange 12 release effort. In the meantime, I'd love to hear your views on the subject.
