They did it!

At 4:53.44 Pacific Time on May 25, the Phoenix Mars Lander successfully touched down in the polar region of Mars. Considering this makes the Mars missions track record only 5 successful out of 11 attempts, that’s no small feat. So far all indications are that the lander is performing exactly as intended, and I hope it continues to do so!

For those that don’t know me, realize that I’m a space sciences junkie. My current favorite series on TV is The Universe, aired on History Channel, but if I come across nearly anything related to space sciences while channel surfing, I usually have to stop and watch I have absolutely no talent for the physics and math involved in such fields, yet I’m still mesmerized by all of it.

Curiously, I don’t have any problem rationalizing my spiritual beliefs in an an Almighty God who has created everything we see with the physical realities of the Universe that we can see with our own eyes. For me, the two go hand-in hand and mutually prove the existence of the other.

Shame on you, Microsoft!

For some reason, when I made the decision to install our new Exchange 2007 server on Windows Server 2008 the thought that backups might be a problem never occurred to me. But reality set in when I tried to run the new Windows Server Backup in Server 2008 (which replaces the venerable NTBackup) to make a quick backup of the Exchange 2007 data store. It was immediately apparent that this new backup tool could not back up Exchange data anymore. Hmmm…

A few minutes of Googling confirmed what I’d just learned. I found articles like this that describe Windows Server Backup’s inability to handle Exchange data, and such blogs are riddled with comments from people who are pretty upset about this change. Microsoft’s answer seems to be to purchase System Center Data Protection Manager, use another third party app that can do VSS (Volume Shadow Copy Service) Exchange backups, or use another third party app that can do ESE streaming backups (which is what NTBackup used to do perfectly well). The irony is that the new Windows Server Backup utility can do VSS backups… but not for Exchange data, which has to be handled in a special way.

I guess for those of you that have Enterprise backup software that can already do Exchange VSS and/or ESE backups this is No Big Deal, but for small shops like ours that (so far) have been getting along just fine by backing up critical data with NTBackup, this truly stinks. One a positive note, MozyPro can supposedly back up Exchange 2007 data running on Windows Server 2008, so at least getting our Exchange data off-site will still be possible (we’ve been using MozyPro to get Exchange 2003 on Windows 2003 data off site for a while now). But I liked having the local backup too, which was nearly universally restorable with NTBackup
Shame on you, Microsoft, for apparently making a marketing decision and removing functionality that has been in a tried-and-true product like NTBackup for over a decade. Hopefully you will see how incredibly bad this decision was and put Exchange backup functionality back into the new Windows Server Backup Utility soon. Having a product that cannot be backed up without third-party help is simply unacceptable…

Church IT Roundtable - Fall ‘08

The Fall 2008 CITRT has been scheduled… check site for all details. For all two of you who read my blog, my primary motivation for posting this is to encourage you (assuming you are a church IT person) to get to the CITRT event if at all possible. It is a great way to network with your peers, make some friends, and feel a little bit less lonely in your IT role

My secondary motivation for making this post is simply to see how many copies of this image

we can get on the CITRT.org site in a single day! Hehe.

Exchange 2007 Upgrade

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 7×146GB 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>
• 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)
• 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.

1. 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.
2. 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.
3. 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.

WSUS Missing Feature?

Is it just me, or is WSUS missing a needed feature? If an update synchronizes with the server and you then approve it, you get the usual “The files for this update have not been downloaded…” message while WSUS is downloading the files. But there seems to be no way to determine how long the download will take or how far it is in the process!

Yeah, 95% of the time I don’t care when the update will come down and just let WSUS do its thing without a second thought, but there are times like now when I have approved an update for a server product and want to apply it now, but WSUS inexplicably gives no indication as to how long the download will take and how far it’s gotten. Would it have been too much for Microsoft to add a graph (not that MS installation graphs have ever been remotely accurate, but still…. lie to me!) Even fake information is better than none at all! (And yes, I know you can configure WSUS to download unapproved updates so they are “ready” when you approve, but that uses disk space I’m not willing to give up).

If I’m an idiot and just can’t see this obvious feature, please educate me!