Server Testing before Production

My wife's job as a technology coordinator is a tough one to be sure. There is never enough time for all the big tasks let alone the minutia. Since I am a "tech guy", I find helping out to be a value to both of us. One of the tasks that my wife gladly allows me to do is that of dealing with studying, planning, preparing and implementing server upgrades. Her organization is going to be implementing a 1:1 laptop program, and with the infrastructure improvements, we need to upgrade server operating systems.

Snow Leopard Server (10.6.x) has served the organization for almost 3 years in admirable fashion. Now that OS X Lion Server is at 10 months of age as of this writing, it is battle tested and patched to the point where it is safe to move the servers to the new OS. However, we never do anything without considerable research and planning. Not only are those steps important, but testing is a key element that so many people avoid.

Today, I am following the following test plan to see how the Snow Leopard to Lion Server upgrade will work on a test Mac Mini. In the first step, I have secured a Mac Mini similar to the actual production server. Both are Mac Mini boxes with Dual Core processors of the same speed. They do vary in the amount of RAM installed (4GB in production versus 2GB in test), however that is the only real difference.

The second step is to get an image from the production server without bringing the machine down for a prolonged period of time. The program I use is called SuperDuper and this program has proven itself over many times. It will repair permissions, then build an image of the production server hard drive to an external device in the form of a disk image. SuperDuper will also preserve the ACL (access control lists) of the production server.

The third step is to take that disk image of the production server's hard drive and image it back to the test server. I have my disk image on an external hard drive that connects via FireWire 800. Boot the Mac Mini test server from DVD or USB key and launch Disk Utility. Then use the "Restore" operation to take the disk image to the text server's hard drive. In my scenario this took about 30 minutes of time since the disk image from the production server contained no data share points. As a note, we always try to keep the data share points off the OS X Server operation system volume.

Once the test server has an identical OS X Server install to the production server, we can begin the process of upgrading the test server to Lion Server. I will not document that process here. The important issue to remember is that you are being safe in testing out whether the upgrade will work prior to committing to the upgrade in a production server environment.

A side benefit is the knowledge that your backup will work should the upgrade fail. On some upgrades, I have been known to do two backup disk images. Taking the server off-line and using Disk Image or SuperDuper are both good methods. While I have not tried Time Machine, it is my understanding that works for OS X Server migrations. In summer 2011, Apple server gurus favored doing the upgrade process over the migration process, which had bugs. Your mileage my vary now that OS X Lion is more mature.

Happy server upgrade paths to you.

MS Office 2011 Debacle

I usually only blog when I have something worthwhile to contribute, or feel compelled. Today I am compelled to blog about a glitch in MS Office 2011 and in particular Outlook 2011 for Mac OS X.

I received a cellphone call on Wednesday morning from a friend and client who uses a MacBook Pro running Lion. The friend had recently done the MS Office 2011 SP2 update that comes via the automatic update feature in Office 2011. Now she was panicking because Outlook would no longer open her email and she was receiving an error message about rebuilding the mail database. I told her I would meet her at the local coffee house (Smokey Row) in a couple hours after doing other IT tasks.

Perhaps some background is in order here. MS Outlook stores its messages in a single database file on the Macintosh under the Documents folder. The subfolder is called Microsoft Identities 2011 which contains the Main Identity. Occasionally, it is probably a good idea for the Outlook user to run the Microsoft Database Utility which rebuilds indices and makes a backup of the database file, but the process is normally a manual one. My friend had only been using the new Outlook since December 2011.

Back to the story. So I meet up with my friend over a cup of house coffee and proceed to look over the error message. Outlook 2011 14.2 (SP2) wants to "upgrade" the old database to conform to the newest format. That process runs for 30 seconds and discovers there are problems with the mail database, so it launches the Microsoft Database Utility, which runs through step one of fixing the database. Oops, a problem occurs. Microsoft Database Utility 14.2 is too new to perform operations on the mail database. We are given an error message and told to use the old Microsoft Database Utility.

OK, at this point I look and discover that the SP2 update from Microsoft does not preserve the older version of the Microsoft Database Utility. So no problem, I get the original media and install Microsoft Database Utility from DVD. I run the Microsoft Database Utility version 14.1 and it reports that it can not fix the mail database, because "I am using the wrong version". Wait a second here, what happened.

Fast forward through an hour of looking at Time Machine backups of the old mail database, and the same errors about versions keeps coming up. By the way Time Machine actually saved the day here, so for those of you who are Mac OS X users, don't be fools - USE TIME MACHINE!

Finishing my cold coffee and ready for a refill, I finally came to a thought that perhaps Microsoft Office 2011 SP1 (14.1.4) had also changed the mail database and that its Microsoft Database Utility was the key. So, I fired up Time Machine and went back to Microsoft Office 2011 SP1 (14.1.4) and tried that Microsoft Database Utility on the mail database. It proceed to fix the problems and make a backup. Then I upgraded to SP2 and processed the mail database by launching Outlook 2011 SP2 and everything worked.

Hey, only took 1 hour and 45 minutes. Part of my problem was that while I use Office 2011 and Word and Excel, I never use Outlook or PowerPoint. I think OS X Mail and Keynote better and they really are better.

To Microsoft programmers, how hard would it be to have the Microsoft Database Utility run prior to performing the SP2 upgrade? There is not even a warning message about potential issues. And the TechNet articles, while painting the process of using Microsoft Database Utility nicely, have no mention of the fact that Microsoft Database Utility versions are particular to the current state of the mail database. The SP2 update process should have maintained the older version of Microsoft Database Utility in case of problems.

I have learned a lot about how MS Office 2011 has issues with regard to its mail component and there is serious room for improvement.