I typically deploy and configure MOSS and not WSS 3.0 farms. Search Server is included in MOSS but not in WSS 3.0 Good thing that Microsoft has a free version of the Search Server 2008. This is the Search Server 2008 Express edition.
Okay, so install Search Server 2008 Express edition on top of WSS 3.0. This upgrades the configuration database of the existing WSS 3.0 farm. (There are many ways to upgrade WSS 3.0 to have Search Server 2008 but what I was doing was upgrading an existing WSS 3.0 farm configuration database.)
SS 2008 Express installation ran fine without any problems. The Configuration Wizard launches after the installation and the Configuration Wizard ran fine too. Now, when you access the Central Admin for the first time after installing SS 2008 Express, instead of default.aspx at the Central Admin site, you get presented with the Search Server Wizard Page instead. It is http://centraladmin/_admin/SearchServerWizard.aspx. Here you can specify the databases and other setttings for your Search Server.
Well, if the SQL Server 2005 hosting the content and config databases is not SP2 or later, you will get the following error message when click the OK button at the Search Server Wizard page:
Search Server has detected that the minimum database server version requirement is not met. The computer that hosts the database server role must have Microsoft SQL Server 2000 with SP3a or later or Microsoft SQL Server 2005 SP2 or later.
The problem is the instructions for installing Search Server 2008 does not mention anything about making sure your SQL Server 2005 is SP2 or higher.
Lesson: make sure you have your SQL Server 2005 upgraded to SP2 or higher before you install Search Server 2008.
Posted by: Gabe Hilado in
SharePoint on April 2nd, 2009
It’s been a while since I’ve worked with WSS 2.0. I have a customer (a friend of mine) who is still running a WSS 2.0 in his business. He runs a small shop and doesn’t have a full-time person to take care of this network and applications. Well, one time he had a FT person but that person left and he’s managing this servers with some help from a PT person.
The WSS 2.0 environment has “moved around” a lot. The front-end and SQL backend has been toasted at least once and the environments had to be recreated from scratch. The only backups they had were SQL backups. The SQL backups were okay.
Now, he wants that WSS 2.0 upgraded to WSS 3.0. I thought, well, this should be easy–only one Web front-end and one SQL server. Also, he had no intention of keeping WSS 2.0. So, just do an in-place upgrade, and it should be done, right?
Well, I ran into problems when I did the pre-upgrade scan prior to running the WSS 3.0 Configuration Wizard. You’re supposed to run the pre-upgrade scan tool prior to upgrading WSS 2.0 sites to WSS 3.0. Otherwise, if you run the Configuration Wizard without running the prescan tool, you will get:
Configuration Failed.
One or more configuration settings failed. Completed configuration settings will not be rolled back. Resolve the problem and run this configuration wizard again.
To run the prescan tool, go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin and execute the following command:
prescan.exe /all
(For more details, see the Microsoft KB article 938216. )
When I ran the prescan tool, I encountered errors and it says on the log file:
Upgrade has encountered one or more lists that were not updated by Prescan.exe and must exit. The most likely reasons for Prescan to skip a list are covered in the Knowledge Base article at: http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409 (http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409) For more information about the lists that are not upgraded, see the upgrade log file.
It seemed like there were orphaned objects. I told you, this WSS 2.0 had been recreated a few times and they used SQL backups to restore the contents. Things have been orphaned or convoluted along the way. Oh yeah, the Web front-end server also had several (non-WSS) virtual sites that were running on port 80; they were differentiated only via the use of host-headers. I couldn’t find the orphaned objects to drop and realized that the I’m stuck and couldn’t proceed with the upgrade. I spent an hour performing the recommendations on how to repair/remove orphaned lists and then I stopped.
So here’s what I did instead:
- Backed up the WSS 2.0 site collection using stsadm
- I restored the WSS 2.0 site collection in a different environment/farm. I used my home lab environment for this.
- I then upgraded my home lab WSS 2.0 to WSS 3.0.
- I backed up the WSS 3.0 site collection using stsadm. Now I have the site upgraded to WSS 3.0.
Only thing I have left to do is cleanup the Web front end server at my customer’s site and re-install WSS 3.0 without the upgrade option. Once WSS 3.0 is installed and configured, I can restore the site collection. I’ll do that tomorrow.
Sometimes, you just have to do what you have to do to get the job done.