A few days ago I was allowed to participate in the fun of upgrading from the Windows SharePoint Services version 3 platform to Microsoft Office SharePoint Server 2007 Standard Edition during an overnight weekend time period so as to limit the exposure of any problems that could crop up during operational hours. This should be a cut and dry right? I mean Microsoft has a fully loaded set of documentation to assist in “Planning and Preparing.” How hard can this really be? I’ve got all the information written out with service accounts, passwords and backup copies of site collections, site definitions and content databases sitting on an external drive – really is this going to be a problem? This is going to be FUN!
Okay, so admittedly, there are a few challenges to this environment. It was originally a WSS v2 environment with a custom site definition utilized by several site collections. But wait, there’s more! This environment was upgraded to WSS v3 with a custom site definition leveraging an upgrade definition file. The additional challenge of the evening in question, which I shall continue to term as fun, included changes in the Microsoft Windows Network Infrastructure going through a spiral of changes. You would think that this wouldn’t be much of an issue, servers cache credentials right, don’t they? Unfortunately, when attempting to upgrade, just as when the initial SharePoint instance is installed, the server will communicate back and forth with Active Directory to confirm the user accounts being utilized.
Rather than take the blue pill and investigate how far the rabbit hole goes, I digress and state that after the networking challenges of the Microsoft Windows Server 2003 Infrastructure were fixed so that the real fun could begin – total time wasted waiting for the domain controllers to be fully accessible and operational, 2.5 hours.
First feat, identify where the custom site definition files reside for this WSS v3. Total time ~ 5 minutes.
Once these were copied over to a network file share I figured that we were in the clear… figured.
Second feat, validate the site backups are operational and the site definitions can be applied prior to restoration to be sure that the environment will be a success. The Gray Ghost accepts nothing less than success mind you – it’s a flaw in some sense. So first step in mitigating risk was to utilize a VMWare VM (easier than building out an entire server blade eh?). And for those of you would ask, yes, I’m using VMWare – I’m still not a fan of Microsoft’s VirtualPC 2007 and I have to say that some of the features and capabilities in the newest Workstation release are pretty sweet. After installing the key components (frameworks for .net 2.0 and 3.0, in addition to good ole trust IIS 6.0) on the VM, I was off and running to installing a base installation of SQL Server 2005 Express with the applicable service pack and WSS v3. All of this to a) test that the custom site definitions, just in case the actual server should kick the bucket, at least there would be a safety net and b) to be sure that the data would restore from the backups. Total time ~ 1.5 hours, apparently there were still some DNS issues cropping up.
Third feat, upgrade MOSS on a WSS v3 platform. This would seem trivial right? Unfortunately, not so much. After running the SharePoint Products and Technologies Configuration Wizard, it made it through 8 of 9 upgrade / installation steps before failing. Sadly there was very little in the actual error log except that an error had occurred. After parsing through the log files I came across an interesting tid bit of information:
Requested registry access is not allowed.
Needless to say, what a let down, and without going and pulling down a copy of regmon and finding out what key it was that SharePoint was trying to modify, and then go about restoring the proper administrative privileges in the registry, I decided that it was time for a surgical strike at the heart of this SharePoint server. Total time ~ 1.5 hours.
Game time… sort of. Checking to see what’s been installed, the server seems to think that MOSS is, even though it’s not entirely installed. So at this point I’m frustrated and decide that I’ve got site collection backups that I’ve made using stsadm and I’ve got the content databases (removed them through the web interface prior to the fun of this evening), it’s time to uninstall MOSS and WSS and just do a fresh install of MOSS. Easier said than done right? Attempt to uninstall MOSS via Add/Remove Programs, no deals Mr. Bond. Hey look, SharePoint Products and Technologies Configuration Wizard again, this time it doesn’t give me the option to remove, but rather just spews an event error stating that I need to complete the upgrade before I can do anything further. Alright, sure, I can do that, I’ll just go in and manually move the files to where they’re supposed to be, modify the appropriate registry keys, fluff the pillows, take the milk money from the neighbourhood kids and start the appropriate services. Wait, I don’t know where the files are supposed to go, and better yet I’m getting sleepy, there’s no way that I’m going to be able to type the appropriate GUIDs for the keys that SharePoint installs into the registry. I’m feeling a little helpless at this point and pondering how quickly I can find Windows Server 2003 media to get back up and operational with a fresh installation pondering to myself if my worst fear had come to fruition, had this server kicked the bucket? I got up and checked the server room, there was no bucket in sight. Press on I say.
Then out of nowhere, it hit me…. psconfig to the rescue… 
If you’re not familiar with psconfig, you really need to get to know this fine young gent that resides in the 12-hive’s bin directory. After running the following:
psconfig -cmd upgrade -force
Low and behold, SharePoint was now done completing and “upgraded”. Ack, Event Viewer has gone mad in the Application log, errors everywhere, lots of red. Quickly got up and checked the server once more, still no bucket. Time to check Add / Remove Programs. Again, SharePoint Products and Technologies Configuration Wizard (the bane of my current existence) rears its head once more. Fortunately, this time it bows before its master and allows me to Remove SharePoint from the server. Once that was completed, I proceeded with uninstalling WSS v3. After a quick reboot of the server and a scan of the Event Viewer for any nefarious errors, in addition to making sure that IIS was cleaned up, it was time to kick off a fresh installation of MOSS 2007. Total time ~ 2 hours.
Once MOSS was operational, I deployed the backed up site definition from the file server, set the files to inherit privileges and like that I was back in action, restoring the site collections successfully. Next up, installing the WSS v3 SP1 and the MOSS SP 1, both of which deployed successfully with no hiccups. SharePoint Products and Technologies Configuration Wizard decided to play friendly this time – I was amazed. Total time ~ 2 hours – the joys of waiting for site collection backups to finish restoring.
Overall experience – I was ecstatic to have added MOSS capabilities. I was more ecstatic to sleep. Just another overnight upgrade with the Ghost with the Most.
