18
Exchange 2007 Upgrade
Posted under Church IT by Jim
We recently completed “phase one” of our migration… oops, I mean transition from Exchange 2003 to 2007, and it went remarkably smooth. Here’s how we did it…
The Plan
The simple plan was to transition from the existing Dell 2650 box running Exchange Server 2003 to a VMWare ESX virtual machine running Exchange Server 2007. Why run something as demanding as Exchange in a virtual machine? I would ask “why not?” The data I was able to gather indicates that Exchange 2007 runs fine on ESX server, especially for shops as small as ours (we have fewer than 150 mailboxes, though we should easily be able to get into several thousand mailboxes on a single VM guest). The biggest risk with doing this (and I’m fully aware of the risk) is that Microsoft support for Exchange 2007 running in a VM is sketchy. The gist is that you may have to replicate an issue in a hardware environment before MS will take a look at the issue you’re having within the VM.
(as an aside, I find this attitude toward VMs utterly ridiculous… not just from MS, but from anyone who won’t support their app under VMWare. Sure, I get it when there is a specialized hardware card involved, but in reality it is easier to support an app in VMWare vs. native hardware, because it is a known environment!! You don’t have to worry about a specific hardware platform, a weird NIC or graphics driver, etc. Software vendors should be clamoring to support their apps in a virtual machine!)
Anyway, to make things even more “interesting”, I decided to run Exchange 2007 on Windows Server 2008 64bit guest instead of Windows Server 2003. Once I found out you could not upgrade a Windows 2003 server running Exchange 2007 to Windows Server 2008, I decided it was worth the risk of running a “brand new” OS that I haven’t had much time to test, because I didn’t want to be stuck with an Exchange box running on Windows Server 2003 with no way to upgrade the OS. (as another aside, I am really impressed with Windows Server 2008. It “just works” and almost seems like it’s what Vista should have been.)
The Transition
I started by installing Windows Server 2008 Standard 64bit into a guest VM. I gave it 4GB memory and dual (virtual SMP) processors running on a VMWare ESX 3.5 server with a single quad core 2.83GHz Xeon procesor and 16GB total memory. We currently have no SAN, so storage is local and consists of 7x146GB 10k SAS drives in a RAID 5 with 512MB write cache on the controller and a hot spare. I then did all the boring things you do to a new server like joining it to the domain, configuring it to get WSUS updates and applying all available patches. After that the transition process went something like this:
- Installed .NET 3.0 and Windows PowerShell components, which are needed by Exchange 2007.
- At a PowerShell prompt, ran ‘ServerManagerCmd -i RSAT-ADDS’. This lets the Windows 2008 box do the necessary AD modifications. Installing this forces a reboot.
- Prepared AD for Exchange 2007 per this article. Specifically, I ran these commands from the mounted Exchange 2007 install DVD:
- setup /PrepareLegacyExchangePermissions
setup /PrepareSchema
setup /PrepareAD /OrganizationName:<your exchange organization>
- setup /PrepareLegacyExchangePermissions
- I then added necessary Windows components per this article. Because this box was going to handle Exchange Hub Transport, Client Access and Mailbox roles, I specifically installed:
- ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression
ServerManagerCmd -i RPC-over-HTTP-proxy (necessary for Outlook Anywhere)
- ServerManagerCmd -i Web-Server
- I then installed Exchange 2007 per this article. The actual install went smooth and was uneventful. The installation recognized that we had an existing Exchange 2003 server and automatically set up the necessary integration to let the two servers communicate.
One of the first things I did after installation was to point our Barracuda Spam Firewall at the new server, so that all inbound mail went to it instead of the old server. I was happy to see all messages come into the new server and then immediately get forwarded on to the old server (because every mailbox still lived there), confirming that the integration of the two servers was working.
SSL
The second thing I did was get an SSL certificate for the new server. Prior to my arrival here there was no SSL certificate of any type on the old Exchange 2003 server… all outlook WebAccess and ActiveSync traffic was flying around in the clear. Knowing that I would be upgrading “soon” I didn’t bother with it, but with the new Exchange 2007 server installed I was determined to do SSL right on this box.
After some brief research, I came to the conclusion that I had two alternatives for doing SSL “right” on an Exchange 2007 server.
- Get a “Unified Communications” certificate, also known as a “SAN” certificate. This is a special type of certificate that lets you associate it with several different hostnames, via a field of the certificate called “Subject Alternate Name” (thus “SAN”, get it?). Why would an Exchange 2007 server need more than one hostname in its certificate? Because it uses SSL for several different services… the server’s hostname, webmail (if it is different than the hostname), autodiscover.company.com, which lets Outlook find Exchange resources via HTTP, differing internal vs. external hostnames, etc. Most importantly, most of these services will not work with a self-signed certificate, or they will break. You must have a certificate signed by a trusted root that Outlook and any browser will readily accept.
- You can configure all of the various Exchange services that need SSL to listen on different IP addresses, and thus use normal “one hostname” traditional SSL certificates on each hostname/IP. For me this was too complicated and unconventional to be worth it. I didn’t want a server set up in such a non-standard way just to save a few bucks on a certificate. Besides, by the time you buy all of the necessary “single server” certificates you’re in the ballpark of a real SAN certificate.
- You, as I did,
may wonder why you can’t use a normal wildcard certificate (*.yourdomain.com) and thus protect all of the various Exchange URLs with a single cert? I’m not sure why this is not recommended, but everywhere I looked seemed to say “it won’t work” or “it’s too much trouble.” At the very least you are likely to have issues with ActiveSync mobile devices that typically don’t trust any wildcard certificates… at least not without manually importing the trusted root. Yuck.
In the end I went with a SAN certificate from Digicert. More on “why” I went with them in a future post. After verifying that all parts of Exchange 2007 were functioning as expected over SSL — including Outlook WebAccess, ActiveSync and Outlook Anywhere, we began the moving of mailboxes…
Moving Mailboxes
Obviously it would have been crazy to simply move all mailboxes from one server to another in one fell swoop. Instead I took a more cautious approach and moved myself first. Moving a mailbox from the old box to the new is about four mouse clicks, and the time it takes varies on the number of messages you have in your mailbox. Once I was confident my mailbox had moved OK and everything looked good, I started moving other guinea pigs onto the new box… starting with some of my most tech-savvy users, so that they would be able to articulate any problems they saw on the new box to me rationally.
So far, everything is looking good! I’m moving people from the old box to the new in a gradual, controlled fashion. This is mainly so that I can keep an eye on the performance metrics of the new box, since it is running in a VM and I want to be certain I see any performance problems creeping up before they become a problem. So far, the box isn’t remotely breaking a sweat and I have every reason to believe it will handle far greater loads than we will place on it for the next few years.
All in all, this Exchange transition has been one of the easiest software upgrades/migrations I’ve ever done. Kudos to Microsoft for getting this one right! Exchange 2007 on Windows 2008 on ESX seems to be a winning combination… at least it is for us.

Add A Comment