This one is really, really, weird.
We use virtual machines in my current project for developers workstations. Those VM contains (amongst other software) Moss, as this current is about Moss (not really but it used it).
So, it was time to upgrade each of the workstations to SP1. We all have heard that it's quite a big step, careful preparation needs to be taken, etc, etc, etc... But what the heck!!! let's have a good time doing it the hard way!!
At the time of writing, we have upgraded two workstations and the process has been different in each of them. Please note that they are VMs based on the same image (in fact one is a "NewSid-ed" copy of the other) so the same behavior would be, at least, desirable.
Well, to make short things short, my colleague installed SP1 as per instructions found in this blog and was unable to update properly. As a result his moss installation was sort of unstable, so he had to recreate all web applications and "import" (attach it as per blog) the content database from a non-updated workstation which fires up the update process in the database.
Just for the sake of it (and to try to save some work recreating all web applications), I tried a slightly different process in my workstation: I detached my content database and after that, I installed the service packs.
Surprisingly (not for me :-p as I expect nothing from nowhere) it worked. So I was happily ready to re-attach my non-upgraded content database in order to kick off the upgrade process. No luck. It was complaining that the database already had an schema in place. Of course if has!!! The very same schema my mate's workstation was happy to allow re-attachment. So, in an exercise of patience, I decided to detach my colleague's database and attach it to my system. No luck either :-(
So I ended up creating a new empty content-database and restoring a backup of my colleague's upgraded one.
The moral of it? Some:
- SP1 acts weird. I am by no means a Moss guru, but it behaved differently in two machines with the same apparent configuration. Why on earth allowing re-attaching a database in one machine and not in another? Still no clue and, to be honest, our clients aren't paying me for investigating issues with Service Packs so I won't go there.
- Meaningful error messages. When it failed in my mate's machine, it came up with an ugly meaningless message that had nothing to do with any of the operations carried out in the process of installation. So we were left with a help link that did not help us in any way and a message that applied to other cases but not ours.
- Maybe I am asking too much, but, in my opinion, a service pack shouldn't take more than a backup, click-click-click-click operation and you are good to go. Anything beyond that shouldn't be ready for being called a final version of a Service Pack.
Now I feel better. Enjoy upgrading your portals...